Seleção de pool de conexão e configurações de parâmetro Jedis recomendadas
Vantagens de pool de conexão Jedis
A comparação entre Lettuce e Jedis é a seguinte:
- Lettuce
- Lettuce não realiza a detecção de manutenção de atividade de conexão. Se existir uma conexão anormal no pool de conexões, um erro será relatado quando o tempo limite das solicitações.
- Lettuce não implementa a validação do pool de conexões, como testOnBorrow. Como resultado, as conexões não podem ser validadas antes de serem usadas.
- Jedis
- Jedis implementa a validação do pool de conexão usando testOnBorrow, testWhileIdle e testOnReturn.
Se testOnBorrow estiver ativado, a validação de conexão será executada quando as conexões estiverem sendo emprestadas, o que tem a maior confiabilidade, mas afeta o desempenho (a detecção é realizada antes de cada solicitação do Redis).
- testWhileIdle pode ser usado para detectar conexões ociosas. Se o limite for definido corretamente, as conexões anormais no pool de conexões poderão ser removidas a tempo de evitar erros de serviço causados por conexões anormais.
- Se uma conexão se tornar anormal antes da verificação de conexão ociosa, o serviço que usa a conexão pode relatar um erro. Você pode especificar o parâmetro timeBetweenEvictionRunsMillis para controlar o intervalo de verificação.
- Jedis implementa a validação do pool de conexão usando testOnBorrow, testWhileIdle e testOnReturn.
Portanto, Jedis tem melhores capacidades de tratamento e detecção de exceções e é mais confiável do que Lettuce em cenários onde há exceções de conexão e jitters de rede.
Configurações de parâmetros recomendadas do pool de conexão Jedis
|
Parâmetro |
Descrição |
Configuração recomendada |
|---|---|---|
|
maxTotal |
Número máximo de conexões |
Defina esse parâmetro com base no número de threads HTTP do contêiner da Web e das conexões reservadas. Supondo que o parâmetro maxConnections do Conector de Tomcat esteja definido como 150 e que cada solicitação HTTP possa enviar simultaneamente duas solicitações ao Redis, é recomendável definir esse parâmetro como pelo menos 400 (150 x 2 + 100). Limite: o valor de maxTotal multiplicado pelo número de nós do cliente (contêineres CCE ou VMs de serviço) deve ser menor que o número máximo de conexões permitidas para uma única instância do DCS Redis. Por exemplo, se maxClients de uma instância principal/em espera do DCS Redis for 10.000 e maxTotal de um único cliente for 500, o número máximo de clientes será 20. |
|
maxIdle |
Número máximo de conexões ociosas |
Defina este parâmetro para o valor de maxTotal. |
|
minIdle |
Número mínimo de conexões ociosas |
Geralmente, é aconselhável definir este parâmetro para 1/X de maxTotal. Por exemplo, o valor recomendado é 100. Em cenários sensíveis ao desempenho, você pode definir esse parâmetro para o valor de maxIdle para evitar o impacto causado por alterações frequentes na quantidade de conexão. Por exemplo, defina este parâmetro como 400. |
|
maxWaitMillis |
Tempo máximo de espera para obter uma conexão, em milissegundos |
O tempo de espera máximo recomendado para obter uma conexão do pool de conexões é o tempo limite máximo tolerável de um único serviço menos o tempo limite para a execução do comando. Por exemplo, se o tempo limite máximo tolerável de HTTP for 15s e o tempo limite de solicitações do Redis for 10s, defina esse parâmetro como 5s. |
|
timeout |
Tempo limite de execução do comando, em milissegundos |
Esse parâmetro indica o tempo limite máximo para execução de um comando do Redis. Defina este parâmetro com base na lógica do serviço. Geralmente, é aconselhável definir esse tempo limite para mais de 210 ms para garantir a tolerância a falhas de rede. Para lógica de detecção especial ou detecção de exceção de ambiente, você pode ajustar esse tempo limite para segundos. |
|
minEvictableIdleTimeMillis |
Tempo de despejo da conexão ociosa, em milissegundos. Se uma conexão não for usada por um período maior do que isso, ela será liberada. |
Se você não quiser que o sistema restabeleça conexões desconectadas com frequência, defina esse parâmetro para um valor grande (xx minutos) ou defina esse parâmetro para –1 e verifique as conexões ociosas periodicamente. |
|
timeBetweenEvictionRunsMillis |
Intervalo para detectar conexões ociosas, em milissegundos |
O valor é estimado com base no número de conexões ociosas no sistema. Por exemplo, se esse intervalo for definido como 30s, o sistema detectará conexões a cada 30s. Se uma conexão anormal for detectada dentro de 30s, ela será removida. Defina este parâmetro com base no número de conexões. Se o número de conexões for muito grande e esse intervalo for muito curto, os recursos de solicitação serão desperdiçados. Se houver centenas de conexões, é aconselhável definir esse parâmetro para 30s. O valor pode ser ajustado dinamicamente com base nos requisitos do sistema. |
|
testOnBorrow |
Indica se a validade da conexão deve ser verificada usando o comando ping ao emprestar conexões do pool de recursos. Conexões inválidas serão removidas. |
Se o serviço for extremamente sensível a conexões e o desempenho for aceitável, você poderá definir esse parâmetro como True. Geralmente, é aconselhável definir esse parâmetro como False para habilitar a detecção de conexão ociosa. |
|
testWhileIdle |
Indica se o comando ping deve ser usado para monitorar a validade da conexão durante o monitoramento de recursos ociosos. Conexões inválidas serão destruídas. |
Verdadeiro |
|
testOnReturn |
Indica se deve verificar a validade da conexão usando o comando ping ao retornar conexões ao pool de recursos. Conexões inválidas serão removidas. |
Falso |
|
maxAttempts |
Número de tentativas de conexão quando o JedisCluster é usado |
Valor recomendado: 3–5. Valor padrão: 5. Defina esse parâmetro com base nos intervalos máximos de tempo limite das APIs de serviço e em uma única solicitação. O valor máximo é 10. Se o valor exceder 10, o tempo de processamento de uma única solicitação é muito longo, bloqueando outras solicitações. |
