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

Cenários

No modo de proxy de cluster nativo da nuvem, os comandos padrão utilizam conexões compartilhadas. Assim, o aumento de conexões do cliente não afeta as conexões do banco de dados de backend. No entanto, certos comandos com estado alteram a conexão entre o proxy e o nó de dados de compartilhada para exclusiva.

No modo exclusivo, cada conexão de cliente cria uma conexão dedicado no nó de dados. Em cenários de alta concorrência, as conexões do nó de dados crescem linearmente junto com as conexões do cliente. Esse comportamento pode desencadear o erro max number of clients reached e causar interrupções no serviço.

O dimensionamento horizontal com a adição de shards não resolve a exaustão de conexões por shard causada por requisições de monitoramento (WATCH) ou bloqueio.

Comandos que ativam o modo exclusivo:

• Comandos de transação: MULTI/EXEC (após WATCH)

• Comandos de bloqueio: BLPOP, BRPOP, BRPOPLPUSH e XREAD ... BLOCK ...

O pool de conexões reutiliza as conexões exclusivas entre o proxy e o nó de dados. Essa abordagem reduz o número de conexões no nó de dados e previne falhas decorrentes do limite máximo de conexões.

Arquitetura

Cada subinstância de proxy executa um pool de conexões independente e mantém um pool dedicado para cada nó de dados.

Exemplo:

Sem um pool de conexões, cada conexão cliente-proxy estabelece uma conexão separada para cada shard de backend. Por exemplo, 10 conexões de cliente acessando 5 shards criam 10 × 5 = 50 conexões.

Com o pool de conexões ativado, o proxy mantém um pool limitado para cada shard, e as requisições do cliente reutilizam as conexões desse pool. No mesmo cenário, as 10 conexões de cliente podem precisar de apenas 2 conexões no pool por shard, totalizando 2 × 5 = 10 conexões.

Fluxo de trabalho:

1. Quando um cliente inicia uma requisição em modo exclusivo, o proxy obtém uma conexão ociosa do pool de conexões do shard de destino.

2. Acerto no pool: O sistema vincula uma conexão ociosa à conexão do cliente para processar a requisição. Após a conclusão, a conexão é desvinculada e devolvida ao pool para reutilização.

3. Falha no pool: O proxy cria uma nova conexão. Depois que a requisição é concluída:

   1. Se o pool não tiver atingido o limite (private_conn_pool_max_idle_per_db), a conexão é adicionada ao pool.

   2. Caso o pool esteja cheio, a conexão é liberada imediatamente (modo de conexão de curta duração).

Esse mecanismo reduz a sobrecarga de gerenciamento de conexões, diminui o consumo de recursos no banco de dados e melhora a estabilidade e o throughput.

Requisitos

Sua instância deve atender aos seguintes requisitos:

• Modo de implantação: Nativo da nuvem. Você pode alterar de clássico para nativo da nuvem.

• Arquitetura da instância: Cluster. É possível alterar a arquitetura de padrão para cluster.

• Modo de conexão: Modo de proxy.

• Versão do proxy: 7.0.17 ou posterior. Se sua versão for anterior, você pode atualizar a versão do proxy.

Ativar o pool de conexões

Ative o pool de conexões modificando um parâmetro da instância. Trata-se de uma atualização a quente que não exige reinicialização nem afeta os serviços em execução.

1. Acesse a página Instances. Na barra de navegação superior, selecione uma região. Em seguida, clique em ID da instância de destino.

2. No painel de navegação à esquerda, clique em Parameter Settings.

3. Localize private_conn_pool_enabled e clique em Modify na coluna Actions.

4. Na caixa de diálogo, defina o valor como 1 e clique em OK.

Para verificar, consulte a métrica Connections from Proxy to DB em Infrastructure Monitoring no console do CloudMonitor e compare os dados antes e depois de ativar o recurso.

Configuração e ajuste

Observações de uso

• **Defina um valor adequado para private_conn_pool_min_idle_per_db**

  Cada conexão ociosa consome memória no nó de banco de dados de backend. Com múltiplos shards e nós de proxy, um valor alto para private_conn_pool_min_idle_per_db pode causar uso excessivo de memória.

• Evite trocas desnecessárias de contexto de banco de dados

  Quando uma conexão do pool é reutilizada por um cliente que acessa um índice de banco de dados diferente, o proxy executa o comando SELECT para trocar o contexto. Isso aumenta a carga útil do banco de dados e a latência. Projete sua aplicação para usar um único índice de banco de dados (geralmente DB 0).

• Não aplicável a comandos de publicação/assinatura

  O pool de conexões não se aplica aos comandos SUBSCRIBE e PSUBSCRIBE. Eles ocupam permanentemente uma conexão e não são gerenciados pelo pool.

Referências

• Arquitetura de cluster

• Recursos do proxy Tair