Documentación de Oracle Cloud Infrastructure

Mejores prácticas de cliente de OCI Cache

Las siguientes mejores prácticas se aplican a todas las interacciones de cliente de OCI Cache, tanto si el cluster de destino funciona en modo sin particiones horizontales como con particiones horizontales. Seguir estas directrices garantiza un comportamiento coherente y mitiga los riesgos operativos comunes. Estas recomendaciones proporcionan orientación general y no pretenden ser una documentación exhaustiva. Para obtener información detallada sobre sus bibliotecas específicas y los casos de uso de Redis o Valkey, consulte los recursos adecuados.

Recomendaciones de configuración y tamaño de cluster

La selección del tamaño de caché adecuado para el cluster le ayuda a optimizar el rendimiento y el uso de recursos. El tamaño de la caché debe reflejar las cargas de trabajo de la aplicación esperadas y ajustarse a los cambios durante los periodos de mayor actividad. OCI Cache le permite escalar o reducir el cluster para que se ajuste a sus necesidades.

Antes de ajustar el tamaño del cluster de caché, tenga en cuenta los patrones de carga de trabajo de su aplicación y las expectativas de crecimiento futuras.

Responda a las siguientes preguntas para elegir el mejor tamaño y configuración para el cluster de caché:
  • ¿Su aplicación tiene mucha lectura o escritura?
    • Resistente a la lectura: si el tamaño de los datos no supera los 500 GB, utilice un cluster sin particiones horizontales y agregue suficientes réplicas de lectura para distribuir el tráfico.
    • Pesado en escritura: si planea almacenar grandes cantidades de datos en la caché, considere un cluster con particiones horizontales. La fragmentación distribuye el tráfico de escritura entre los nodos, lo que genera un mayor rendimiento y evita cuellos de botella.
    • Lectura y escritura: utilice un cluster con particiones horizontales con réplicas de lectura para cada partición horizontal. Esta configuración proporciona alta disponibilidad y escalabilidad para ambas cargas de trabajo.
  • ¿Cómo elige el tamaño de caché correcto?

    Defina el tamaño de la caché en al menos un 50 % más grande que el tamaño de datos actual. Este buffer gestiona picos inesperados en las cargas de trabajo hasta que se cambia el tamaño del cluster.

  • ¿Cómo puede planificar futuros aumentos de la capacidad de almacenamiento o escritura?

    Cree un cluster con particiones horizontales para mayor flexibilidad. Los clusters con particiones horizontales facilitan la ampliación del almacenamiento y la capacidad de escritura a medida que aumentan los requisitos.

  • ¿Cuándo debe utilizar varias bases de datos en la caché?

    Si la aplicación necesita separar los datos en la misma caché para distintos fines, como el almacenamiento en caché y la gestión de sesiones, seleccione un cluster sin particiones horizontales y ajuste el parámetro de bases de datos según sea necesario. El soporte para varias bases de datos solo está disponible en clusters no con particiones horizontales.

  • ¿Puede ejecutar scripts de Lua en un cluster con particiones horizontales?

    Utilizar un cluster no fragmentado para los scripts de Lua. Las secuencias de comandos de Lua requieren que todas las claves a las que se hace referencia residan en la misma ranura, que es más fácil de gestionar sin fragmentación.

Compatibilidad de biblioteca de cliente

Utilizar bibliotecas de cliente que sean totalmente compatibles con OCI Cache. Las versiones mínimas recomendadas incluyen Lechuga (6.x o posterior, especialmente para el soporte de clusters con particiones horizontales) y Redisson (3.36.0 o posterior), que admiten funciones como Seguridad de capa de transporte (TLS) y mecanismos de autenticación requeridos por OCI Cache. Pruebe siempre las nuevas versiones de la biblioteca en un entorno temporal antes de desplegarlas en producción para garantizar la compatibilidad y la estabilidad.

En la siguiente tabla, se muestran las versiones mínimas compatibles de las bibliotecas de cliente para varios lenguajes de programación que soportan el modo de cluster (fragmentación) en OCI Cache, junto con las notas relevantes sobre las capacidades de soporte de cluster.

Matriz de compatibilidad para bibliotecas de cliente
Biblioteca (idioma) Enlace GitHub Versión mínima compatible Notas de soporte de cluster
redes-py (Python) red/redis-py 5+ Soporte de modo de cluster nativo desde la versión 5.0.0
Lechuga (Java) lechuga 6,3 Soporte completo de cluster
Jedis (Java) jedis 3,1 Cluster soportado mediante JedisCluster
Redisson (Java) redisson 3,36 Soporta completamente el cluster de Redis
redis-rb (Ruby) redis-rb 5,3 Requiere gema de redis-clusters
red-rs (Rust) red-rs 0,26 Soporte parcial; el modo de cluster puede variar según el caso de uso
phpredis (PHP) phpredis 6+ Soporte de cluster a través de RedisCluster
Go-Redis (Go) ir-redis v9.6.1 Soporta completamente el modo de cluster
StackExchange.Redis (Nº C) StackExchange.Redis No admitido Requiere AllowAdmin=true, carece de compatibilidad completa con el cluster; no se admite la comunicación de nombre de host
ServiceStack.Redis (Nº C) ServiceStack.Redis No admitido No se admite el modo de cluster
cluster contratado (C) cluster-contratado No admitido No se admite la comunicación de nombre de host

Optimización de conexiones

Nota

Las siguientes sugerencias son para las acciones que se deben realizar en el código de aplicación. También puede implementar retrocesos exponenciales.
  • Activar pool de conexiones: reutilice las conexiones existentes para reducir la sobrecarga que supone establecer otras nuevas para cada solicitud. Esta práctica evita el agotamiento de recursos y mejora el rendimiento de la aplicación. Ajuste los tamaños de los pools en función de la simultaneidad de la aplicación y la capacidad del cluster. Defina parámetros como el mínimo o máximo de conexiones inactivas, los timeouts de conexión y los tiempos de espera máximos para las conexiones.
  • Defina los tiempos de espera adecuados para los comandos y las conexiones, normalmente entre 2000 ms y 5000 ms, a fin de evitar retrasos durante las interrupciones de la red o los retrasos del servidor.
  • Configurar mecanismos de reintento: establezca políticas de reintento para manejar fallos transitorios, como interrupciones de red. Por ejemplo, configure tres intentos de reintento con un intervalo de 1000 ms entre intentos para ayudar a garantizar la recuperación.
  • Gestionar conexiones inactivas: cierre las conexiones no utilizadas para evitar fugas y liberar recursos, lo que impide que el nodo de caché supere su límite de conexión.

Conformidad de seguridad y TLS

  • OCI Cache exige TLS para todas las conexiones de cliente por defecto. TLS siempre está activado en el puerto 6379. Puede permitir el acceso TCP adicional en el puerto 7379 si es necesario. Asegúrese de que las bibliotecas de cliente admitan la versión 1.2 o posterior de TLS y utilice los conjuntos de cifrado actuales para mantener canales de comunicación seguros.
  • Si el rendimiento es fundamental, colabora con los equipos de soporte y seguridad de OCI para evaluar el impacto de la sobrecarga de TLS. La desactivación de TLS en entornos de producción no se recomienda debido a las vulnerabilidades de seguridad.

Mejores prácticas para la seguridad

Protege tu OCI Cache desde el principio para evitar el acceso no autorizado y las vulnerabilidades. Si bien OCI Cache exige TLS para todas las conexiones de cliente por defecto, las medidas de seguridad adicionales son críticas para los entornos de producción.

  • Restringir acceso: configure políticas de red para permitir conexiones solo desde redes de confianza o host local. Evite exponer los puntos finales de OCI Cache a la red pública de Internet.
  • Establece una autenticación segura: Asegúrate de que existan contraseñas robustas o mecanismos de autenticación según las directrices de seguridad de OCI para evitar el acceso no autorizado. Además, utilice el soporte de enrutamiento de paquetes de confianza cero y grupo de seguridad de red (NSG) en el servicio para aplicar el acceso basado en políticas a las instancias de OCI Cache. Este enfoque mejora aún más la seguridad al restringir el acceso solo a las entidades autorizadas.
  • Desactivar comandos peligrosos: limite el acceso a comandos potencialmente dañinos como FLUSHALL y CONFIG para evitar la pérdida accidental o maliciosa de datos en Redis.
  • Uso de configuraciones protegidas: utilice las funciones de seguridad integradas de OCI Cache y revise periódicamente los controles de acceso para mantener un entorno seguro.

Gestión de claves y caducidad

No es necesario definir un tiempo de vida (TTL) para cada clave. Algunas claves pueden persistir indefinidamente. Sin embargo, se recomienda definir valores TTL razonables para la mayoría de las claves. La configuración de TTL ayuda a evitar que los datos desactualizados u huérfanos permanezcan en la caché. Este enfoque garantiza la frescura de los datos y el uso eficiente de la memoria.

Cuando la caché alcance su límite de memoria, puede configurar el parámetro maxmemory-policy para eliminar automáticamente las claves según la política de expulsión seleccionada. Esta configuración ayuda a optimizar la gestión de memoria.

Supervisión y configuración de alertas

  • Supervise métricas clave, como el uso de memoria, y defina alertas para umbrales (por ejemplo, cuando el uso supere el 80 % durante 30 minutos) para evitar condiciones de falta de memoria y fallos de cluster. La supervisión continua es esencial para mantener el rendimiento de OCI Cache a medida que evolucionan las cargas de trabajo.
    • Activar el registro detallado: utilice herramientas como SLOWLOG para identificar comandos lentos antes de que afecten al rendimiento.
    • Revise los logs con regularidad: compruebe si hay advertencias, errores o patrones inusuales en los logs de OCI Cache para evitar incidencias.
    • Supervise la memoria y las tasas de expulsión: realice un seguimiento de la frecuencia de expulsión de claves junto con las métricas existentes, como el uso de memoria (por ejemplo, por encima del 80 % durante 30 minutos) para ajustar los límites de memoria o las políticas de forma proactiva.
  • Realice un seguimiento de las métricas, incluidas las conexiones conectadas, las conexiones rechazadas y la latencia de comandos, para identificar y resolver cuellos de botella o anomalías. Supervise los ratios de aciertos y faltas de caché para detectar un uso ineficiente y ajustar las políticas de clave o expulsión según sea necesario.
  • Defina alarmas para otras métricas, como eventos de expulsión y recuento de conexiones, para mantener el estado del cluster.
  • Cambie el tamaño del cluster si el uso de memoria incumple de manera consistente el límite o si el uso de CPU indica operaciones de escritura más altas.

Uso de comandos optimizado

  • Minimice el uso de comandos O(n), como KEYS. En su lugar, utilice SCAN, HSCAN o SSCAN.
  • No utilice comandos como KEYS o SMEMBERS en juegos de datos grandes, ya que pueden congelar las operaciones de Redis. En su lugar, utilice comandos iterativos como SCAN, SSCAN y HSCAN para recorrer los datos sin bloquear el sistema
  • Consulte la lista de comandos no soportados en la documentación de OCI Cache para garantizar el cumplimiento de los requisitos de compatibilidad para los clusters con particiones horizontales.
  • Almacene los datos relacionados en hashes en lugar de varias claves únicas para ahorrar memoria y acelerar las consultas en entornos Redis.
  • Utilizar la canalización para enviar varios comandos a la vez, reduciendo los tiempos de ida y vuelta, y configurar el pool de conexiones para mantener tiempos de respuesta bajos y minimizar la sobrecarga

Mejores prácticas de cliente para clusters no fragmentados

Los clusters no con particiones horizontales en OCI Cache funcionan con un nodo primario y nodos de réplica opcionales, replicando datos en todos los nodos para garantizar una alta disponibilidad. Utilice estas prácticas para maximizar la disponibilidad y el rendimiento.

Configuración de alta disponibilidad

  • Despliegue clusters con al menos tres nodos (una principal y dos réplicas) para garantizar una alta disponibilidad. OCI Cache distribuye los nodos entre los dominios de errores y los dominios de disponibilidad para mejorar la resiliencia frente a fallos localizados.
  • Las operaciones de escritura directa al punto final principal y el uso de puntos finales de réplica para las operaciones de lectura para distribuir la carga y mejorar la redundancia.
  • Flexibilice las aplicaciones mediante la especificación de puntos finales en los archivos de configuración para soportar cualquier cambio de cluster debido a failovers o eventos de escala.

Mejores prácticas de cliente para clusters con particiones horizontales

Los clusters con particiones horizontales en los datos de partición de OCI Cache en varias particiones horizontales, cada una con un nodo principal y réplicas opcionales para ofrecer escalabilidad y rendimiento. Las siguientes prácticas son específicas para los clientes que interactúan con clusters con particiones horizontales, abordando los desafíos únicos de la gestión de datos distribuidos.

Selección de clientes compatibles con el cluster

Para obtener un rendimiento y una escalabilidad óptimos, utilice bibliotecas de clientes que admitan el modo de cluster y la resolución de nombres de host. Al seleccionar un cliente, priorice las bibliotecas con soporte explícito para el modo de cluster Redis y la resolución del nombre de host, como Lettuce (versión 6.x o posterior) o Redisson (versión 3.36.0 o posterior).

Además de las bibliotecas mencionadas en la matriz de compatibilidad, como Lechuga (versión 6.x o posterior) y Redisson (versión 3.36.0 o posterior), hay otras bibliotecas disponibles para varios lenguajes de programación que pueden admitir clusters con particiones horizontales. Para obtener una lista completa de las bibliotecas de cliente compatibles, consulte la documentación de Valkey.

Asegúrese de que el cliente seleccionado pueda gestionar dinámicamente los cambios de topología y la asignación de espacios sin intervención manual. Esta capacidad es esencial para operaciones de cluster perfectas.

Configuración de punto final para resiliencia

  • Configure aplicaciones para especificar puntos finales primarios para al menos tres particiones horizontales distintas (por ejemplo, nodos con nombres de host que terminan en -1-1, -2-1 y -3-1) a fin de garantizar la conectividad si una partición horizontal o un nodo no están disponibles.
  • Flexibilice las aplicaciones especificando puntos finales en los archivos de configuración. Este enfoque permite a la aplicación adaptarse a los cambios del cluster que resultan de los failovers o los eventos de escala.
  • Utilice el punto final de detección, que no cambia durante la vida útil del cluster.

Detección automática de topologías

  • Active las bibliotecas de cliente para recuperar y refrescar periódicamente la información de topología de cluster al iniciar o en tiempo de ejecución. Este enfoque permite a los clientes adaptarse al failover del nodo o al cambio de tamaño del cluster sin actualizar las configuraciones.
  • Utilice el punto final de detección, que permanece igual durante toda la vida útil del cluster.

Soporte de escalabilidad y alta disponibilidad

  • Utilice bibliotecas de clientes que admitan la reconexión y el reajuste automáticos para mantener las aplicaciones en ejecución durante el cambio de tamaño del cluster (por ejemplo, al agregar o eliminar particiones horizontales).
  • Configure cada partición horizontal con al menos dos y hasta cuatro réplicas para soportar el failover y la alta disponibilidad. OCI Cache distribuye particiones horizontales entre los dominios de disponibilidad y los dominios de errores para mejorar la resiliencia.

Supervisión de métricas de cluster con particiones horizontales

  • Defina alertas para métricas críticas, incluido el uso de memoria (por ejemplo, por encima del 80 % durante 30 minutos) y la disponibilidad de los nodos.
  • Supervise las métricas de nivel de nodo para cada partición horizontal, como el uso de memoria, para decidir la mejor distribución de datos entre particiones horizontales y garantizar un rendimiento equilibrado del cluster.