Tair (Redis® OSS-Compatible):Troca imperceptível

Migração de dados no Redis Cluster de código aberto: princípios e pontos de dor

O Redis Cluster de código aberto migra Slots usando a abordagem Per Key, concluindo a migração de um único Slot ao percorrer e migrar chaves em lotes. O fluxo específico é o seguinte:

1. Defina o status de importação no shard de destino.

2. Defina o status de migração no shard source.

3. Recupere a lista de chaves do Slot a ser migrado do shard source.

4. Envie o comando migrate para o shard source com um lote de chaves. O comando migrate é síncrono e bloqueante. Ele envia as chaves para o shard de destino para restauração e, em seguida, as exclui do source. Isso se repete até que a lista de chaves esteja vazia.

5. Use o comando setslot para atribuir o Slot migrado ao nó de destino.

A abordagem de migração Per Key apresenta os seguintes pontos de dor:

• O comando migrate é síncrono e bloqueante, impedindo o processamento de outras requisições. A migração de chaves grandes causa bloqueios prolongados.

• Quando uma chave não existe no shard source, a requisição é redirecionada para o shard de destino, adicionando um salto extra de roteamento.

• Requisições de comandos de múltiplas chaves podem receber um erro TRYAGAIN.

• Os dados de um único Slot são distribuídos por dois shards. Se ocorrer uma exceção, a migração não poderá ser revertida de forma tranquila.

Migração de dados sem interrupções baseada na replicação de Slots do Tair

Com base na replicação primário-réplica, o Tair desenvolveu a tecnologia de replicação de Slots (Slot Mig) no nível do kernel. Ele sincroniza dados entre nós replicando Slots, em combinação com um controlador central (CS) que controla o bloqueio de gravação Slot Wait no nível de milissegundos. Quando a topologia do cluster é alterada, as requisições do cliente são redirecionadas por meio da semântica MOVED.

O fluxo específico da migração Slot Mig é o seguinte:

1. O CS envia o comando de migração slotRepl para o shard de destino.

2. O nó de destino envia um comando slotPsync para o nó source.

3. O nó source gera um snapshot do Slot a ser migrado.

4. O nó de destino recebe os dados do snapshot.

5. O nó source sincroniza os dados incrementais com o nó de destino.

6. O CS avalia dinamicamente a lacuna de sincronização e envia slotReplWait para bloquear gravações no nível de milissegundos. Se o bloqueio exceder o limiar, uma reversão é acionada automaticamente.

7. O CS altera a topologia do cluster após a conclusão da sincronização. As requisições antigas do cliente são redirecionadas pela semântica MOVED.

8. O nó source exclui os dados do Slot migrado.

A migração Slot Mig apresenta as seguintes vantagens:

• Nenhum erro de somente leitura e nenhuma queda de conexão.

• Semântica MOVED apenas após a alteração de topologia, sem semântica ASK.

• Chaves grandes e requisições de múltiplas chaves não são afetadas.

• Os dados de um único Slot não são mais divididos, e o processo pode ser revertido em uma única etapa.

Comparação: Tair Slot Mig vs. Per Key da comunidade

Observações

• No modo de conexão direta, o cliente deve lidar com comandos MOVED.

• No modo de proxy, a redução de dimensionamento libera nós de proxy, causando quedas de conexão. O cliente deve ter capacidade de reconexão.

• Comandos que não são de dados (como PING, INFO), além dos comandos PUB/SUB e BLOCKING, não podem ser redirecionados automaticamente após a migração de Slots. atualize periodicamente a tabela de roteamento da aplicação.

• Para garantir a consistência dos dados, a latência de requisições de gravação para o Slot correspondente pode aumentar durante a etapa final da migração, mas não falhará.

Camada de kernel: protocolo REDIRECT

O Tair implementou o protocolo de troca imperceptível no nível do kernel, que foi integrado à comunidade Valkey. O novo formato de protocolo é REDIRECT HOST PORT, em que REDIRECT indica que o cliente deve redirecionar a requisição para o nó de destino.

Camada de cliente: suporte a SDK

O Tair implementou o suporte a trocas imperceptíveis no cliente Valkey-Java. Para conexões em trânsito, um mecanismo de bloqueio de duas camadas controla a reinicialização do pool de conexões: a primeira camada usa o tryLock do ReentrantLock para renovação de candidatos, e a segunda usa o ReentrantReadWriteLock para controle de leitura e gravação.

atualize os clientes para o Valkey-Java 5.3.0 ou posterior:

<dependency>
  <groupId>io.valkey</groupId>
  <artifactId>valkey-java</artifactId>
  <version>5.3.0</version>
</dependency>

Camada de rede: Connection Draining

O Tair usa uma arquitetura "LB + VIP". Após a troca de VIP, o mecanismo Connection Draining mantém as conexões antigas ativas por um período configurável, garantindo que o primário antigo tenha tempo suficiente para entregar o comando REDIRECT antes de encerrar a conexão de forma controlada.

Limitações do dimensionamento sem interrupções na arquitetura de cluster

• A instância deve usar discos cloud.

• A instância deve usar a arquitetura de cluster.

• Versões suportadas: Redis OSS 5.0 (secundária 5.2.0+), 6.0 (secundária 6.0.2.0+), 7.0; Tair Memory-Optimized compatível com Redis 5.0 (secundária 5.0.34+), 6.0, 7.0; Tair Persistent Memory; Tair Disk-Based.

• O cliente deve lidar com comandos MOVED (modo direto) ou ter capacidade de reconexão (modo de proxy).

Limitações da troca imperceptível na arquitetura standalone

A troca imperceptível para a arquitetura standalone possui os seguintes requisitos de versão secundária:

• Redis OSS: Apenas a versão 7.0, versão secundária 0.2.9 ou posterior.

• Tair (Enterprise): Todas as versões principais, versão secundária 25.11.0.0 ou posterior.