Mejores prácticas generales - Amazon ElastiCache

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Mejores prácticas generales

A continuación, encontrará información sobre las prácticas recomendadas para utilizar las interfaces Valkey, Redis OSS y Memcached incluidas en ellas. ElastiCache

  • Utilice configuraciones habilitadas para el modo de clúster: el modo de clúster habilitado permite que la caché se escale horizontalmente para lograr un mayor almacenamiento y rendimiento que una configuración con el modo de clúster deshabilitado. ElastiCache La configuración sin servidor solo está disponible en una configuración habilitada para el modo de clúster.

  • Utilice conexiones de larga duración: crear una nueva conexión es caro y requiere tiempo y CPU recursos de la memoria caché. Reutilice las conexiones siempre que sea posible (por ejemplo, mediante la agrupación de conexiones) para amortizar este coste a lo largo de muchos comandos.

  • Lectura desde réplicas: si utiliza réplicas de lectura ElastiCache sin servidor o ha aprovisionado réplicas de lectura (clústeres de diseño propio), dirija las lecturas a las réplicas para lograr una mejor escalabilidad o una latencia más baja. Las lecturas desde réplicas acaban siendo coherehentes con la principal.

    En un clúster de autodiseño, evite dirigir las solicitudes de lectura a una única réplica de lectura, ya que es posible que las lecturas no estén disponibles temporalmente si el nodo falla. Configure su cliente para que dirija las solicitudes de lectura al menos a dos réplicas de lectura, o dirija las lecturas a una única réplica y a la principal.

    En los sistemas ElastiCache sin servidor, la lectura desde el puerto de réplica (6380) dirigirá las lecturas a la zona de disponibilidad local del cliente siempre que sea posible, lo que reducirá la latencia de recuperación. Cuando se produzca un error, volverá automáticamente a los demás nodos.

  • Evitar los comandos costosos: evite ejecutar operaciones que hagan una utilización intensiva de procesamiento y de E/S, como los comandos KEYS y SMEMBERS. Recomendamos este enfoque porque estas operaciones aumentan la carga en el clúster e influyen en el rendimiento del clúster. En su lugar, utilice los comandos SCAN y SSCAN.

  • Seguir las prácticas recomendadas de Lua: evite los scripts Lua de ejecución prolongada y siempre declare por adelantado las claves que utiliza en los scripts Lua. Recomendamos este enfoque para determinar que el script Lua no está utilizando comandos de ranura cruzada. Asegúrese de que las claves utilizadas en scripts Lua pertenezcan a la misma ranura.

  • Utilice pub/sub fragmentado: cuando utilice Valkey o Redis OSS para soportar cargas de trabajo de pub/sub con un alto rendimiento, le recomendamos que utilice pub/sub fragmentado (disponible con Valkey y con Redis 7 o versiones posteriores). OSS El pub/sub tradicional en los clústeres habilitados para el modo de clúster transmite mensajes a todos los nodos del clúster, lo que puede generar un nivel alto de EngineCPUUtilization. Tenga en cuenta que en los comandos pub/sub tradicionales sin servidor utilizan internamente comandos pub/sub fragmentados. ElastiCache

Temas