Desarrollo con Azure Managed Redis (versión preliminar)
Resistencia de la conexión y carga del servidor
Al desarrollar aplicaciones cliente, asegúrese de tener en cuenta los procedimientos recomendados sobre resistencia de la conexión y administración de la carga del servidor.
Consideración de más claves y valores más pequeños
Azure Managed Redis (versión preliminar) funciona mejor con valores más pequeños. Para repartir datos entre varias claves, considere la posibilidad de dividir los fragmentos de datos más grandes en otros más pequeños. Para obtener más información sobre el tamaño de valor ideal, consulte este artículo.
Tamaño de solicitud o respuesta grande
Una solicitud/respuesta grande puede provocar tiempos de espera agotados. Por ejemplo, suponga que el valor del tiempo de expiración configurado en el cliente es de 1 segundo. La aplicación solicita dos claves (por ejemplo, "A" y "B") al mismo tiempo (con la utilización de la misma conexión de red física). La mayoría de clientes admiten la canalización de las solicitudes, en la que ambas solicitudes, "A" y "B", se envían una tras otra sin tener que esperar las respuestas. El servidor vuelve a enviar las respuestas en el mismo orden. Si la respuesta "A" es grande, puede consumir la mayor parte del tiempo de expiración para las solicitudes posteriores.
En el ejemplo siguiente, las solicitudes "A" y "B" se envían rápidamente al servidor. El servidor empieza a enviar las respuestas "A" y "B" rápidamente. Debido a los tiempos de transferencia de datos, la respuesta "B" debe esperar a que se agote el tiempo de espera de la respuesta "A", aunque el servidor haya respondido con rapidez.
|-------- 1 Second Timeout (A)----------|
|-Request A-|
|-------- 1 Second Timeout (B) ----------|
|-Request B-|
|- Read Response A --------|
|- Read Response B-| (**TIMEOUT**)
Esta solicitud/respuesta es difícil de medir. Puede instrumentar el código del cliente para realizar un seguimiento de las respuestas y solicitudes grandes.
Las resoluciones para los tamaños grandes de respuesta varían, pero incluyen lo siguiente:
- Optimización de la aplicación para un gran número de valores pequeños, en lugar de unos pocos valores grandes.
- La mejor solución es dividir los datos en valores menores relacionados.
- Consulte la publicación What is the ideal value size range for redis? Is 100KB too large? (¿Cuál es el intervalo de tamaño de valor ideal para Redis? ¿100 KB es demasiado grande?) para obtener detalles de por qué se recomiendan valores más pequeños.
- Aumento del tamaño de la máquina virtual (VM) para obtener mayores capacidades de ancho de banda
- Un aumento de ancho de banda en la máquina virtual del cliente o servidor puede reducir los tiempos de transferencia de datos para respuestas más grandes.
- Compare la utilización actual de la red en ambas máquinas con los límites del tamaño actual de la máquina virtual. Más ancho de banda solo en el servidor o solo en el cliente puede no ser suficiente.
- Aumente el número de objetos de conexión que usa la aplicación.
- Use un enfoque round robin para realizar solicitudes a través de objetos de conexión distintos.
Uso de canalización
Intente elegir un cliente de Redis que admita la canalización de Redis. La canalización ayuda a hacer un uso eficaz de la red y a obtener el mejor rendimiento posible.
Evita operaciones costosas
Algunas operaciones de Redis, como el comando KEYS son muy costosas y deben evitarse. En Comandos de larga duración encontrará algunos aspectos que tener en cuenta en relación a estos comandos.
Elija un nivel apropiado:
Azure Managed Redis ofrece niveles optimizados para memoria, equilibrados, optimizados para proceso y optimizados para Flash. Vea más información sobre cómo elegir un nivel aquí. Se recomienda realizar pruebas de rendimiento para elegir el nivel correcto y validar la configuración de conexión. Para obtener más información, consulte Pruebas de rendimiento.
Elegir un modo de disponibilidad adecuado
Azure Managed Redis ofrece la opción de habilitar o deshabilitar la configuración de alta disponibilidad. Cuando el modo de alta disponibilidad está deshabilitado, los datos de la instancia de AMR no se replicarán y, por tanto, la instancia de Redis no estará disponible durante el mantenimiento. Todos los datos de la instancia de AMR también se perderán en caso de mantenimiento planeado o no planeado. Se recomienda deshabilitar la alta disponibilidad solo para las cargas de trabajo de desarrollo o pruebas. El rendimiento de las instancias de Redis con alta disponibilidad también podría ser menor debido a la falta de replicación de datos, que es fundamental distribuir la carga entre la partición de datos principal y la réplica.
Cliente en la misma región que la instancia de Redis
Localice su instancia de Redis y su aplicación en la misma región. Si se conecta a una Redis de una región diferente puede aumentar significativamente la latencia y reducir la confiabilidad.
Aunque puede conectarse desde fuera de Azure, no se recomienda, especialmente cuando se usa Redis para acelerar el rendimiento de la aplicación o la base de datos. Si solo usa el servidor de Redis como almacén de clave/valor, es posible que la latencia no sea su principal preocupación.
Confiar en el nombre de host, no en la dirección IP pública
La dirección IP pública asignada a la instancia de AMR puede cambiar como consecuencia de una operación de escalado o una mejora del back-end. Se recomienda confiar en el nombre de host en lugar de en una dirección IP pública explícita.
Uso de cifrado TLS
Azure Managed Redis requiere de manera predeterminada comunicaciones cifradas mediante TLS. Actualmente se admiten las versiones de TLS 1.2 y 1.3. Si la biblioteca o herramienta cliente no admite TLS, es posible habilitar conexiones sin cifrar.
Supervisión del uso de memoria, métricas de uso de CPU, conexiones de cliente y ancho de banda de red
Al usar la instancia de Azure Managed Redis en producción, se recomienda establecer alertas para las métricas "Porcentaje de memoria usada", "CPU", "Clientes conectados". Si estas métricas superan constantemente el 75 %, considere la posibilidad de escalar la instancia a una memoria mayor o a un nivel de rendimiento superior. Consulte cuándo escalar para obtener más detalles.
Considere la posibilidad de habilitar la persistencia de datos o la copia de seguridad de datos
Redis está diseñado para datos efímeros de forma predeterminada, lo que significa que, en raras ocasiones, los datos se pueden perder debido a varias circunstancias, como mantenimiento o interrupciones. Si la aplicación es sensible a la pérdida de datos, se recomienda habilitar la persistencia de datos o la copia de seguridad periódica de datos mediante la operación de exportación de datos.
La característica de persistencia de datos está diseñada para proporcionar automáticamente un punto de recuperación rápido para los datos cuando una memoria caché deja de funcionar. La recuperación rápida se hace posible almacenando el archivo RDB o AOF en un disco administrado montado en la instancia de caché. Los archivos de persistencia en el disco no son accesibles para los usuarios ni se pueden usar en ninguna otra instancia de AMR.
Muchos clientes quieren usar la persistencia para realizar copias de seguridad periódicas de los datos en su caché. No se recomienda usar la persistencia de datos de esta manera. En su lugar, use la característica import/export. Puede exportar copias de datos en formato RDB directamente a la cuenta de almacenamiento elegida y desencadenar la exportación de datos con la frecuencia que necesite. Estos datos exportados se pueden importar a cualquier instancia de Redis. La exportación se puede desencadenar desde el portal o mediante la CLI, PowerShell o las herramientas del SDK.
Guía específica de bibliotecas cliente
Para más información, consulte Bibliotecas cliente de Azure Managed Redis