Selección del grupo de conexiones y configuración recomendada de parámetros de Jedis
Ventajas del grupo de conexión de Jedis
La comparación entre Lettuce y Jedis es la siguiente:
- Lettuce
- Lettuce no realiza la detección keepalive de la conexión. Si existe una conexión anormal en el grupo de conexión, se reporta un error cuando se agota el tiempo de espera de las solicitudes.
- Lettuce no implementa la validación del grupo de conexión como testOnBorrow. Como resultado, las conexiones no se pueden validar antes de ser utilizadas.
- Jedis
- Jedis implementa la validación de grupo de conexión usando testOnBorrow, testWhileIdle y testOnReturn.
Si testOnBorrow está habilitado, la validación de la conexión se realiza cuando se toman las conexiones, lo que tiene la mayor fiabilidad pero afecta al rendimiento (la detección se realiza antes de cada solicitud de Redis).
- testWhileIdle se puede utilizar para detectar las conexiones inactivas. Si el umbral está ajustado correctamente, las conexiones anormales en el grupo de conexión se pueden eliminar a tiempo para evitar errores de servicio causados por las conexiones anormales.
- Si una conexión se vuelve anormal antes de la comprobación de la conexión inactiva, el servicio que utiliza la conexión puede informar de un error. Puede especificar el parámetro timeBetweenEvictionRunsMillis para controlar el intervalo de comprobación.
- Jedis implementa la validación de grupo de conexión usando testOnBorrow, testWhileIdle y testOnReturn.
Por lo tanto, Jedis tiene las mejores capacidades de manejo y detección de excepciones y es más confiable que Lettuce en los escenarios donde hay excepciones de conexión y jitter de la red.
Configuración recomendada del parámetro del grupo de conexión de Jedis
|
Parámetro |
Descripción |
Configuración recomendada |
|---|---|---|
|
maxTotal |
Número máximo de conexiones |
Establezca este parámetro en función del número de subprocesos HTTP del contenedor web y de las conexiones reservadas. Se supone que el parámetro maxConnections del Tomcat Connector está establecido en 150 y cada solicitud de HTTP puede enviar simultáneamente dos solicitudes a Redis, se recomienda establecer este parámetro en al menos 400 (150 x 2 + 100). Limit: el valor de maxTotal multiplicado por el número de nodos de cliente (contenedores de CCE o máquinas virtuales de servicio) debe ser menor que el número máximo de las conexiones permitidas para una sola instancia de DCS Redis. Por ejemplo, si maxClients de una instancia de DCS Redis principal/en espera es 10,000 y maxTotal de un cliente único es 500, el número máximo de clientes es 20. |
|
maxIdle |
Número máximo de conexiones inactiva |
Establezca este parámetro en el valor de maxTotal. |
|
minIdle |
Número mínimo de conexiones inactiva |
Por lo general, se recomienda establecer este parámetro en 1/X de maxTotal. Por ejemplo, el valor recomendado es 100. En los escenarios sensibles al rendimiento, puede establecer este parámetro en el valor de maxIdle para evitar el impacto causado por los cambios frecuentes en la cantidad de conexión. Por ejemplo, establezca este parámetro en 400. |
|
maxWaitMillis |
Tiempo máximo de espera para obtener una conexión, en milisegundos |
El tiempo de espera máximo recomendado para obtener una conexión desde el grupo de conexión es el tiempo de espera máximo tolerable de un solo servicio menos el tiempo de espera para la ejecución del comando. Por ejemplo, si el tiempo máximo de espera HTTP tolerable es 15s y el tiempo de espera de las solicitudes de Redis es 10s, establezca este parámetro en 5s. |
|
timeout |
Tiempo de espera de ejecución de comandos, en milisegundos |
Este parámetro indica el tiempo de espera máximo para ejecutar un comando Redis. Establezca este parámetro basado en la lógica del servicio. Por lo general, se recomienda establecer este tiempo de espera a más de 210 ms para garantizar la tolerancia a fallas de red. Para la lógica de detección especial o la detección de excepciones de entorno, puede ajustar este tiempo de espera a segundos. |
|
minEvictableIdleTimeMillis |
Tiempo de desahucio de conexión inactiva, en milisegundos. Si una conexión no se utiliza durante un período mayor que este, se liberará. |
Si no desea que el sistema restablezca con frecuencia las conexiones desconectadas, establezca este parámetro en un valor grande (xx minutos) o establezca este parámetro en –1 y compruebe las conexiones inactivas periódicamente. |
|
timeBetweenEvictionRunsMillis |
Intervalo para detectar las conexiones inactivas, en milisegundos |
El valor se estima en función del número de conexiones inactivas en el sistema. Por ejemplo, si este intervalo se establece en 30s, el sistema detecta conexiones cada 30s. Si se detecta una conexión anormal dentro de los 30 segundos, se eliminará. Establezca este parámetro en función del número de conexiones. Si el número de conexiones es demasiado grande y este intervalo es demasiado corto, los recursos de solicitud se desperdiciarán. Si hay cientos de conexiones, se recomienda establecer este parámetro en 30s. El valor se puede ajustar dinámicamente en función de los requisitos del sistema. |
|
testOnBorrow |
Indica si se debe comprobar la validez de la conexión mediante el comando ping cuando se toman prestadas conexiones del grupo de recursos. Se eliminarán las conexiones no válidas. |
Si su servicio es extremadamente sensible a las conexiones y el rendimiento es aceptable, puede establecer este parámetro en True. Por lo general, se recomienda establecer este parámetro en False para habilitar la detección de la conexión inactiva. |
|
testWhileIdle |
Indica si se debe utilizar el comando ping para supervisar la validez de la conexión durante la supervisión de los recursos inactivos. Las conexiones no válidas serán destruidas. |
Verdadero (True) |
|
testOnReturn |
Indica si se debe comprobar la validez de la conexión mediante el comando ping al devolver conexiones al grupo de recursos. Se eliminarán las conexiones no válidas. |
Falso (False) |
|
maxAttempts |
Número de reintentos de conexión cuando se utiliza JedisCluster |
Valor recomendado: 3–5. Valor predeterminado: 5. Establezca este parámetro en función de los intervalos máximos de tiempo de espera de las API de servicio y de una sola solicitud. El valor máximo es de 10. Si el valor excede de 10, el tiempo de procesamiento de una sola solicitud es demasiado largo, bloqueando otras solicitudes. |
