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.
A continuación, encontrará información sobre las prácticas recomendadas para utilizar las interfaces OSS de Valkey, Memcached y Redis 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 en 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 recursos de CPU 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 menor latencia. 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
KEYSySMEMBERS. 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 comandosSCANySSCAN.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 la publicación/suscripción en particiones: cuando utilice Valkey o Redis OSS para admitir cargas de trabajo de publicación/suscripción con un alto rendimiento, le recomendamos que utilice la publicación/suscripción en particiones
(disponible con Redis OSS 7 o versiones posteriores). 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 ElastiCache tradicionales sin servidor. pub/sub commands internally use sharded pub/sub
Temas
