Tair (Redis® OSS-Compatible):Otimização do pool de recursos JedisPool

Uso

Este exemplo usa o Jedis 2.9.0. Dependência Maven:

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
    <scope>compile</scope>
</dependency>

O Jedis usa o Apache Commons-pool2 para gerenciar o pool. A classe principal de parâmetros é a GenericObjectPoolConfig:

GenericObjectPoolConfig jedisPoolConfig = new GenericObjectPoolConfig();
jedisPoolConfig.setMaxTotal(...);
jedisPoolConfig.setMaxIdle(...);
jedisPoolConfig.setMinIdle(...);
jedisPoolConfig.setMaxWaitMillis(...);
...

Inicialize um JedisPool:

// redisHost is the IP address of the instance. redisPort is the port of the instance. redisPassword is the password of the instance. timeout is both the connection timeout and the read/write timeout.
JedisPool jedisPool = new JedisPool(jedisPoolConfig, redisHost, redisPort, timeout, redisPassword);
// Execute commands as follows.
Jedis jedis = null;
try {
    jedis = jedisPool.getResource();
    // Specific commands.
    jedis.executeCommand()
} catch (Exception e) {
    logger.error(e.getMessage(), e);
} finally {
    // In JedisPool mode, the Jedis object is returned to the resource pool.
    if (jedis != null) 
        jedis.close();
}

Parâmetros

O JedisPool gerencia conexões Jedis em um pool limitado e seguro para threads. Configurar adequadamente a GenericObjectPoolConfig melhora o desempenho do Redis e reduz a sobrecarga de recursos. As tabelas a seguir descrevem os principais parâmetros e as configurações recomendadas.

Os quatro parâmetros abaixo controlam a detecção de conexões ociosas.

A classe JedisPoolConfig estende a GenericObjectPoolConfig com os seguintes padrões de detecção de ociosidade:

public class JedisPoolConfig extends GenericObjectPoolConfig {
  public JedisPoolConfig() {
    setTestWhileIdle(true);
    setMinEvictableIdleTimeMillis(60000);
    setTimeBetweenEvictionRunsMillis(30000);
    setNumTestsPerEvictionRun(-1);
    }
}

Configurações recomendadas para parâmetros principais

maxTotal (conexões máximas)

Considere os fatores abaixo ao definir o maxTotal:

• Concorrência esperada do Redis.

• Tempo de execução dos comandos no lado do cliente.

• Recursos disponíveis do Redis. O número de nós (instâncias ECS da aplicação) multiplicado pelo maxTotal não pode exceder o limite máximo de conexões da instância. Consulte a página de detalhes da instância para verificar esse limite.

• Sobrecarga de recursos causada por conexões ociosas e dimensionamento frequente do pool.

Exemplo: se o tempo médio de comando (obtenção + execução + rede) for de 1 ms, uma única conexão suporta cerca de 1.000 QPS. Para atingir 50.000 QPS em uma única instância (QPS total / número de shards), o valor teórico do maxTotal seria 50.000 / 1.000 = 50.

Adicione uma margem acima do valor teórico. No entanto, superdimensionar o maxTotal desperdiça recursos do cliente e do servidor, sem resolver problemas de bloqueio causados por comandos pesados.

maxIdle e minIdle

O maxIdle representa o pico real de conexões que sua carga de trabalho necessita, enquanto o maxTotal fornece uma margem de segurança. Evite configurar o maxIdle muito baixo, pois isso força o pool a criar frequentemente novas conexões new Jedis. Já o minIdle controla a detecção de recursos ociosos.

O melhor desempenho ocorre quando o maxTotal é igual ao maxIdle, evitando a sobrecarga de redimensionamento do pool. Iguale esses valores se sua carga de trabalho apresentar picos de tráfego. Caso a concorrência seja baixa ou o maxIdle esteja muito alto, as conexões ociosas serão desperdiçadas.

Estime o tamanho do pool por nó com base no QPS total e na quantidade de instâncias cliente.

Use monitoramento para obter valores adequados

Em produção, utilize JMX ou outras ferramentas de monitoramento para determinar os valores ideais conforme os padrões reais de uso.

Perguntas frequentes

Recursos insuficientes

As situações abaixo impedem a obtenção de um recurso do pool.

• Timeout:

  redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
  …
  Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
  at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449)

• O parâmetro blockWhenExhausted está definido como false, então a chamada não aguarda a liberação de um recurso:

  redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
  …
  Caused by: java.util.NoSuchElementException: Pool exhausted
  at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:464)

Essa exceção nem sempre indica tamanho insuficiente do pool. Ela também pode resultar de problemas de rede, parâmetros mal configurados, monitoramento JMX, ausência de chamadas jedis.close(), consultas lentas ou falhas de DNS. Consulte as Configurações recomendadas para parâmetros principais.

Aquecimento do JedisPool

O JedisPool não cria conexões antecipadamente durante a inicialização. A primeira solicitação dispara uma conexão new Jedis, o que adiciona latência. Com um timeout pequeno, isso pode causar timeouts na inicialização. Para evitar esse problema, pré-carregue conexões com base no minIdle após a criação do pool:

List<Jedis> minIdleJedisList = new ArrayList<Jedis>(jedisPoolConfig.getMinIdle());

for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
    Jedis jedis = null;
    try {
        jedis = pool.getResource();
        minIdleJedisList.add(jedis);
        jedis.ping();
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
    } finally {
    }
}

for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
    Jedis jedis = null;
    try {
        jedis = minIdleJedisList.get(i);
        jedis.close();
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
    } finally {
    
    }
}

Para outros erros, consulte Erros comuns.