Connection pool best practices | Redis cluster proxy - Tair (Redis® OSS-Compatible)

El pool de conexiones en el modo proxy de clúster reutiliza las conexiones entre el proxy y la base de datos. Esto evita que los comandos con estado agoten las conexiones al backend y garantiza la estabilidad de su instancia de Tair (compatible con Redis OSS).

Escenarios

En el modo proxy de clúster nativo de la nube, los comandos estándar utilizan conexiones compartidas, por lo que el aumento de conexiones del cliente no afecta las conexiones a la base de datos del backend. Sin embargo, ciertos comandos con estado cambian la conexión entre el proxy y el nodo de datos de modo compartido a modo exclusivo.

En el modo exclusivo, cada conexión de cliente crea una conexión dedicada en el nodo de datos. Bajo una alta concurrencia, las conexiones del nodo de datos crecen linealmente con las conexiones del cliente. Esto puede desencadenar un error de max number of clients reached y causar interrupciones en el servicio.

El escalado horizontal mediante la adición de shards no resuelve el agotamiento de conexiones por shard causado por solicitudes de vigilancia o bloqueo.

Comandos que activan el modo exclusivo:

Comandos de transacción: MULTI/EXEC (después de WATCH)
Comandos de bloqueo: BLPOP, BRPOP, BRPOPLPUSH y XREAD ... BLOCK ...

El pool de conexiones reutiliza las conexiones exclusivas entre el proxy y el nodo de datos. Esto reduce las conexiones en el nodo de datos y previene fallos por exceso del límite de conexiones.

Arquitectura

Cada subinstancia de proxy ejecuta un pool de conexiones independiente y mantiene un pool dedicado para cada nodo de datos.

Ejemplo:

Sin un pool de conexiones, cada conexión cliente-proxy establece una conexión separada con cada shard del backend. Por ejemplo, 10 conexiones de cliente que acceden a 5 shards crean 10 × 5 = 50 conexiones.

Con el pool de conexiones habilitado, el proxy mantiene un pool limitado para cada shard y las solicitudes del cliente reutilizan las conexiones del pool. Por ejemplo, las mismas 10 conexiones de cliente pueden requerir solo 2 conexiones en el pool por shard, lo que suma un total de 2 × 5 = 10 conexiones.

Flujo de trabajo:

Cuando un cliente inicia una solicitud en modo exclusivo, el proxy obtiene una conexión inactiva del pool de conexiones del shard destino.
Acierto en el pool: Se asigna una conexión inactiva a la conexión del cliente para la solicitud. Al finalizar, la conexión se libera y regresa al pool para su reutilización.
Fallo en el pool: El proxy crea una nueva conexión. Una vez completada la solicitud:
1. Si el pool no ha alcanzado el límite (private_conn_pool_max_idle_per_db), la conexión se agrega al pool.
2. Si el pool está lleno, la conexión se libera inmediatamente (modo de conexión de corta duración).

Esto reduce la sobrecarga de gestión de conexiones, disminuye el consumo de recursos en la base de datos y mejora la estabilidad y el throughput.

Requisitos

Su instancia debe cumplir con los siguientes requisitos:

Modo de despliegue: Nativo de la nube. Puede change from classic to cloud native.
Arquitectura de la instancia: Clúster. Puede change the architecture de estándar a clúster.
Modo de conexión: Modo proxy.
Versión del proxy: 7.0.17 o posterior. Si su versión es anterior, puede upgrade the proxy version.

Habilitar el pool de conexiones

Habilite el pool de conexiones mediante la modificación de un parámetro de la instancia. Esta es una actualización en caliente que no requiere reinicio ni afecta los servicios en ejecución.

Vaya a la página de Instancias. En la barra de navegación superior, seleccione una región. Luego, haga clic en el ID de la instancia objetivo.
En el panel de navegación izquierdo, haga clic en Parameter Settings.
Busque private_conn_pool_enabled y haga clic en Modify en la columna Actions.
En el cuadro de diálogo, establezca el valor en 1 y haga clic en OK.

Para comprobarlo, revise la métrica Connections from Proxy to DB en Infrastructure Monitoring dentro de la consola de CloudMonitor y compare los datos antes y después de habilitar la función.

Configuración y ajuste

Nombre de la configuración	Descripción	Valor predeterminado	Rango de valores
`private_conn_pool_enabled`	Habilita o deshabilita el pool de conexiones. `1`: habilitado. `0`: deshabilitado.	0	`[0	1]`
`private_conn_idle_time_sec`	TTL para conexiones inactivas en el pool, en segundos. Las conexiones inactivas que superan este umbral se cierran. `0`: cerrar inmediatamente.	60	`[0-4294967295]`
`private_conn_pool_max_idle_per_db`	Número máximo de conexiones inactivas que cada nodo de proxy mantiene por nodo de datos. Al alcanzar este límite, las conexiones liberadas se cierran en lugar de regresar al pool.	1000	`[0-4294967295]`
`private_conn_pool_min_idle_per_db`	Número mínimo de conexiones inactivas que cada nodo de proxy mantiene por nodo de datos. Las conexiones por debajo de este umbral se conservan aunque excedan `private_conn_idle_time_sec`.	0	`[0-4294967295]`

Recomendaciones de ajuste

Escenarios generales: Utilice los valores predeterminados, ya que son adecuados para la mayoría de las cargas de trabajo.
Escenarios de transacciones de corta duración y alta concurrencia (como ventas flash)
- Características: Conexiones de corta duración con ciclos frecuentes de préstamo y devolución.
- Recomendación: Establezca private_conn_pool_max_idle_per_db lo suficientemente alto para cubrir las solicitudes concurrentes máximas. Esto maximiza la reutilización y evita conexiones de corta duración. Opcionalmente, reduzca private_conn_idle_time_sec para liberar recursos más rápido durante las horas de menor actividad.
Escenarios de servicios con bloqueos prolongados (como consumidores de colas)
- Características: Conexiones mantenidas por largo tiempo que rara vez regresan al pool.
- Recomendación: Aumente private_conn_pool_max_idle_per_db para igualar el número de consumidores concurrentes. Establezca private_conn_pool_min_idle_per_db ligeramente por encima del promedio de conexiones concurrentes para preobtener conexiones y reducir la latencia en nuevos consumidores.
Escenarios con restricciones de memoria o instancias pequeñas
- Características: Presupuesto de memoria estricto.
- Recomendación: Reduzca private_conn_pool_max_idle_per_db y private_conn_pool_min_idle_per_db. Esto sacrifica cierta eficiencia de reutilización a cambio de reducir el consumo de memoria en los nodos de datos.

Notas de uso

**Establezca un valor razonable para private_conn_pool_min_idle_per_db**

Cada conexión inactiva consume memoria en el nodo de base de datos del backend. Con varios shards y nodos de proxy, un valor alto de private_conn_pool_min_idle_per_db puede provocar un uso excesivo de memoria.
Evite cambios innecesarios de contexto de base de datos

Cuando un cliente que accede a un índice de base de datos diferente reutiliza una conexión del pool, el proxy ejecuta un comando SELECT para cambiar el contexto. Esto aumenta la carga útil de la base de datos y la latencia. Diseñe su aplicación para usar un único índice de base de datos (generalmente DB 0).
No aplica para comandos de publicación/suscripción

El pool de conexiones no aplica para los comandos SUBSCRIBE y PSUBSCRIBE. Estos ocupan permanentemente una conexión y el pool no los gestiona.

Tair (Redis® OSS-Compatible):Connection pool best practices for cluster proxy mode