En esta página se ofrecen directrices sobre cómo usar Memorystore for Redis Cluster de forma óptima. En esta página también se indican los posibles problemas que se deben evitar.
Prácticas recomendadas para gestionar la memoria
En esta sección se describen estrategias para gestionar la memoria de las instancias de forma que Memorystore for Redis Cluster funcione de forma eficiente en tu aplicación.
Conceptos de gestión de la memoria
Carga de escritura: el volumen y la velocidad a los que añades o actualizas claves en tu clúster de Redis. La carga de escritura puede variar de normal a muy alta en función de tu caso práctico de Redis y de los patrones de uso de la aplicación.
Política de desalojo: Memorystore for Redis Cluster usa la
volatile-lrupolítica de desalojo. Puedes usar comandos como EXPIRE para definir desalojos de claves.
Monitorizar un clúster que tiene una carga de escritura normal
Consulta la métrica /cluster/memory/maximum_utilization. Si /cluster/memory/maximum_utilization es igual o inferior al 100 %, tu clúster de Redis funciona correctamente cuando usas una carga de escritura normal.
Sin embargo, si el uso de memoria se acerca al 100% y prevé que el uso de datos aumente, debe aumentar el tamaño del clúster para dejar espacio para los nuevos datos.
Monitorizar un clúster con una carga de escritura alta
Consulta la métrica /cluster/memory/maximum_utilization. En función de la gravedad de la carga de escritura alta, tu clúster puede experimentar problemas de rendimiento en los siguientes umbrales:
Si las cargas de escritura son muy altas, pueden producirse problemas si
/cluster/memory/maximum_utilizationalcanza el 65% o más.Si las cargas de escritura son moderadamente altas, pueden producirse problemas si
/cluster/memory/maximum_utilizationalcanza el 85% o más.
En estos casos, deberías aumentar el tamaño del clúster para mejorar el rendimiento.
Si tienes algún problema o te preocupa que tu instancia tenga una carga de escritura alta, ponte en contacto con el equipo de Asistencia deGoogle Cloud .
Escalar fragmentos
Cuando escales el número de particiones de una instancia, debes hacerlo durante los periodos de pocas escrituras. Si se escala durante periodos de carga de escritura alta, la instancia puede sufrir presión de memoria debido a la sobrecarga de memoria causada por la replicación o la migración de ranuras.
Si tu caso práctico de Redis usa desalojos de claves, reducir el tamaño del clúster puede disminuir la proporción de aciertos de caché. Sin embargo, en este caso no tienes que preocuparte por perder datos, ya que la expulsión de claves es algo esperado.
En los casos prácticos de Redis en los que no quieras perder claves, solo debes reducir el tamaño del clúster a uno más pequeño que siga teniendo espacio suficiente para tus datos. El nuevo número de particiones de destino debe ser al menos 1,5 veces la memoria utilizada por los datos. En otras palabras, debes aprovisionar suficientes particiones para que quepan 1,5 veces la cantidad de datos que hay actualmente en tu clúster. Puede usar la métrica /cluster/memory/total_used_memory para ver la cantidad de datos almacenados en su instancia.
Prácticas recomendadas para el uso de la CPU
Si se produce una interrupción zonal inesperada, los recursos de CPU de tu clúster se reducirán debido a la pérdida de capacidad de los nodos de la zona no disponible. Te recomendamos que uses clústeres de alta disponibilidad. Si se usan dos réplicas por partición (en lugar de una), se proporcionan recursos de CPU adicionales durante una interrupción. Además, te recomendamos que gestiones el uso de la CPU de los nodos para que tengan suficiente margen de CPU para gestionar el tráfico adicional de la capacidad perdida si se produce una interrupción zonal inesperada. Debes monitorizar el uso de la CPU de los elementos principales y las réplicas con la métrica /cluster/cpu/maximum_utilization.
En función del número de réplicas que aprovisiones por nodo, te recomendamos los siguientes /cluster/cpu/maximum_utilizationobjetivos de uso de CPU:
- En las instancias con una réplica por nodo, el valor de
/cluster/cpu/maximum_utilizationdebe ser de 0,5 segundos para el nodo principal y de 0,5 segundos para la réplica cuando esta se designe como réplica de lectura. - En el caso de las instancias con dos réplicas por nodo, el valor de
/cluster/cpu/maximum_utilizationdebe ser de 0,8 segundos para la réplica principal y de 0,5 segundos para cada réplica.
Si los valores de la métrica superan estas recomendaciones, le recomendamos que aumente el número de particiones o réplicas de su instancia.
Comandos de Redis que consumen muchos recursos
Te recomendamos que no uses comandos de Redis que consuman muchos recursos. Si usas estos comandos, pueden producirse los siguientes problemas de rendimiento:
- Latencia alta y tiempos de espera del cliente
- Presión de memoria causada por comandos que aumentan el uso de memoria
- Pérdida de datos durante la replicación y la sincronización de nodos porque el hilo principal de Redis está bloqueado
- Comprobaciones del estado, observabilidad y replicación
En la siguiente tabla se muestran ejemplos de comandos de Redis que consumen muchos recursos y se ofrecen alternativas que consumen menos.
| Categoría | Comando que requiere muchos recursos | Alternativa eficiente en cuanto a recursos |
|---|---|---|
| Se ejecuta en todo el espacio de claves | KEYS |
SCAN |
| Ejecutar para un conjunto de claves de longitud variable | LRANGE |
Limita el tamaño del intervalo que usas en una consulta. |
ZRANGE |
Limita el tamaño del intervalo que usas en una consulta. | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| Bloquear la ejecución de una secuencia de comandos | EVAL |
Asegúrate de que tu secuencia de comandos no se ejecute indefinidamente. |
EVALSHA |
Asegúrate de que tu secuencia de comandos no se ejecute indefinidamente. | |
| Eliminar archivos y enlaces | DELETE |
UNLINK |
| Publicar y suscribirse | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Prácticas recomendadas para clientes de Redis
Tu aplicación debe usar un cliente de Redis compatible con clústeres al conectarse a una instancia de Memorystore for Redis Cluster. Para ver ejemplos de clientes compatibles con clústeres y configuraciones de muestra, consulta Ejemplos de código de la biblioteca de cliente. Tu cliente debe mantener un mapa de los segmentos de hash a los nodos correspondientes del clúster para enviar solicitudes a los nodos correctos y evitar la sobrecarga de rendimiento causada por las redirecciones del clúster.
Asignación de clientes
Los clientes deben obtener una lista completa de los espacios y los nodos asignados en las siguientes situaciones:
Cuando se inicializa el cliente, debe rellenar la asignación inicial de ranuras a nodos.
Cuando se recibe una redirección
MOVEDdel servidor, como en el caso de una conmutación por error en la que la réplica se hace cargo de todos los espacios que servía el nodo principal anterior, o en el caso de un refragmentación en el que los espacios se mueven del nodo principal de origen al nodo principal de destino.Cuando se recibe un error
CLUSTERDOWNdel servidor o las conexiones a un servidor concreto superan el tiempo de espera de forma persistente.Cuando se recibe un error
READONLYdel servidor. Esto puede ocurrir cuando un elemento principal se degrada a réplica.Además, los clientes deben actualizar periódicamente la topología para que estén preparados para cualquier cambio y para conocer los cambios que no provoquen redirecciones o errores del servidor, como cuando se añaden nuevos nodos de réplica. Ten en cuenta que las conexiones obsoletas también deben cerrarse como parte de la actualización de la topología para reducir la necesidad de gestionar las conexiones fallidas durante el tiempo de ejecución del comando.
Descubrimiento de clientes
La detección de clientes suele hacerse enviando un comando CLUSTER SLOT, CLUSTER NODE o CLUSTER SHARDS al servidor Redis. Te recomendamos que uses el comando CLUSTER SHARDS. CLUSTER SHARDS sustituye al comando CLUSTER SLOTS (obsoleto) y proporciona una representación más eficiente y extensible del clúster.
El tamaño de la respuesta de los comandos de descubrimiento de clientes de clústeres puede variar en función del tamaño y la topología del clúster. Los clústeres más grandes con más nodos producen una respuesta mayor. Por lo tanto, es importante asegurarse de que el número de clientes que realizan el descubrimiento de la topología del clúster no aumente sin límite.
Estas actualizaciones de la topología son costosas en el servidor Redis, pero también son importantes para la disponibilidad de las aplicaciones. Por lo tanto, es importante asegurarse de que cada cliente haga una sola solicitud de descubrimiento en un momento dado (y almacene en caché el resultado en la memoria) y de que el número de clientes que hagan las solicitudes se mantenga limitado para evitar sobrecargar el servidor.
Por ejemplo, cuando la aplicación cliente se inicia o pierde la conexión con el servidor y debe realizar el descubrimiento del clúster, un error habitual es que la aplicación cliente realice varias solicitudes de reconexión y descubrimiento sin añadir retroceso exponencial al reintentar. Esto puede hacer que el servidor Redis deje de responder durante un periodo prolongado, lo que provoca un uso muy elevado de la CPU.
Evitar la sobrecarga de descubrimiento en Redis
Para mitigar el impacto causado por una afluencia repentina de solicitudes de conexión y descubrimiento, te recomendamos que hagas lo siguiente:
Implementa un grupo de conexiones de cliente con un tamaño finito y pequeño para limitar el número de conexiones entrantes simultáneas de la aplicación cliente.
Cuando el cliente se desconecta del servidor debido a un tiempo de espera agotado, vuelve a intentarlo con retroceso exponencial con fluctuación. De esta forma, se evita que varios clientes sobrecarguen el servidor al mismo tiempo.
Usa el endpoint de descubrimiento de Memorystore for Redis Cluster para descubrir clústeres. El endpoint de descubrimiento tiene una alta disponibilidad y la carga se balancea entre todos los nodos del clúster. Además, el endpoint de descubrimiento intenta enrutar las solicitudes de descubrimiento de clústeres a los nodos con la vista de topología más actualizada.
Prácticas recomendadas de persistencia
En esta sección se explican las prácticas recomendadas para la persistencia.
Persistencia de RDB y adición de réplicas
Para obtener los mejores resultados al crear copias de seguridad de tu instancia con copias de seguridad de RDB o al añadir réplicas a tu instancia, sigue estas prácticas recomendadas:
Gestión de la memoria
Las copias de seguridad de RDB usan una bifurcación de procesos y un mecanismo de copia al escribir para crear una copia de seguridad de los datos de los nodos. En función del patrón de escritura en los nodos, la memoria utilizada de los nodos aumenta a medida que se copian las páginas afectadas por las escrituras. La huella de memoria puede ser hasta el doble del tamaño de los datos del nodo.
Para asegurarte de que los nodos tengan suficiente memoria para completar la instantánea, mantén o define maxmemory en el 80% de la capacidad del nodo para que el 20% se reserve para la sobrecarga. Esta sobrecarga de memoria, además de las monitorizaciones de las instantáneas, te ayuda a gestionar tu carga de trabajo para que las instantáneas se creen correctamente. Además, cuando añadas réplicas, reduce el tráfico de escritura tanto como sea posible. Consulta Monitorizar un clúster con una carga de escritura alta para obtener más información.
Capturas obsoletas
Recuperar nodos a partir de una copia de seguridad obsoleta puede provocar problemas de rendimiento en tu aplicación, ya que intentará conciliar una cantidad significativa de claves obsoletas u otros cambios en tu base de datos, como un cambio de esquema. Si te preocupa recuperarte de una copia obsoleta, puedes inhabilitar la función de persistencia de RDB. Una vez que vuelvas a habilitar la persistencia, se hará una captura en el siguiente intervalo de capturas programado.
Impacto en el rendimiento de las copias de seguridad de RDB
En función del patrón de carga de trabajo, las copias de seguridad de RDB pueden afectar al rendimiento de la instancia y aumentar la latencia de las aplicaciones. Puedes minimizar el impacto en el rendimiento de las copias de seguridad de RDB programándolas para que se ejecuten durante periodos de poco tráfico de instancias si no te importa que las copias de seguridad se creen con menos frecuencia.
Por ejemplo, si tu instancia tiene poco tráfico de 1:00 a 4:00, puedes definir la hora de inicio a las 3:00 y el intervalo en 24 horas.
Si tu sistema tiene una carga constante y requiere instantáneas frecuentes, debes evaluar detenidamente el impacto en el rendimiento y sopesar las ventajas de usar instantáneas RDB para la carga de trabajo.
Añadir una réplica
Para añadir una réplica, se necesita una instantánea de RDB. Para obtener más información sobre las instantáneas de RDB, consulta Gestión de memoria.
Elige una instancia de una sola zona si tu instancia no usa réplicas
Cuando configures una instancia sin réplicas, te recomendamos que uses una arquitectura de una sola zona para mejorar la fiabilidad. Estos son los motivos:
Minimizar el impacto de las interrupciones
Es menos probable que las interrupciones zonales afecten a tu instancia. Si colocas todos los nodos en una sola zona, la probabilidad de que una interrupción zonal afecte a tu servidor se reduce del 100% al 33%. Esto se debe a que hay un 33% de probabilidades de que la zona en la que se encuentra tu instancia deje de funcionar, frente al 100% de probabilidades de que los nodos ubicados en la zona no disponible se vean afectados.
Recuperación rápida
Si se produce una interrupción zonal, la recuperación se simplifica. Puedes responder aprovisionando rápidamente una nueva instancia en una zona que funcione y redirigiendo tu aplicación para que las operaciones se interrumpan lo mínimo posible.
Prácticas recomendadas para lechugas
En esta sección se describen las prácticas recomendadas para usar Lettuce para conectarse a una instancia de Memorystore for Redis Cluster.
Actualizar los valores de los parámetros
Si usas Lettuce, cambia el parámetro validateClusterNodeMembership por false. De lo contrario, cuando cambie la topología, es posible que se produzcan errores unknownPartition.