Se o seu cluster Tair (compatível com Redis OSS) apresentar pressão de memória, gargalos de CPU ou rede, ou capacidade superprovisionada, aumente a escala para adicionar shards ou reduza a escala para removê-los. Diferentemente dos clusters Redis open source, o Tair elimina os erros -ASK e -TRYAGAIN, comuns durante a migração de slots. Assim, sua aplicação continua atendendo às solicitações sem interrupções.
Como funciona
O Tair modifica a lógica de replicação de dados do kernel para migrar dados slot por slot, em vez de chave por chave. Um componente de controle centralizado gerencia o processo, evita a divisão de slots e garante que cada migração seja atômica. A migração no nível de slot é concluída muito mais rápido do que a migração no nível de chave e elimina os erros transitórios de redirecionamento -ASK e -TRYAGAIN que os clientes receberiam de outra forma.
Durante a fase final da migração de cada slot, a latência das solicitações de escrita para o slot afetado aumenta temporariamente. As solicitações de escrita não falham.
No Redis Serialization Protocol (RESP) para clusters, comandos que não envolvem dados, como PING e INFO, além de famílias especiais de comandos como PUB/SUB e BLOCKING, não são redirecionados automaticamente após uma migração de slot. A camada de aplicação deve atualize periodicamente a tabela de rotas para obter a topologia mais recente após o dimensionamento.
Principais recursos
|
Recurso |
Descrição |
|
Gerenciamento eficiente de dimensionamento |
Um componente de controle centralizado oferece controle preciso e eficiente sobre o comportamento do cluster. |
|
Migração atômica de dados |
Cada slot migra de forma atômica. Não ocorre divisão de slots e os clientes nunca recebem erros |
|
Migração mais rápida |
A migração slot por slot é concluída significativamente mais rápido do que a migração chave por chave. |
|
Auto Scaling |
O Tair suporta Auto Scaling para lidar com cargas de trabalho flutuantes sem intervenção manual. |
Instâncias compatíveis
O dimensionamento sem interrupções requer:
Modo de implantação: cloud-native
Arquitetura: cluster
As seguintes versões de instância são compatíveis:
|
Tipo de instância |
Versões compatíveis |
|
Redis Open-Source Edition 5.0 |
Versão secundária 5.2.0 ou posterior |
|
Redis Open-Source Edition 6.0 |
Versão secundária 6.0.2.0 ou posterior |
|
Redis Open-Source Edition 7.0 |
Todas as versões |
|
Tair (Enterprise Edition) otimizada para memória, compatível com Redis 5.0 |
Versão secundária 5.0.34 ou posterior |
|
Tair (Enterprise Edition) otimizada para memória, compatível com Redis 6.0 |
Todas as versões |
|
Tair (Enterprise Edition) otimizada para memória, compatível com Redis 7.0 |
Todas as versões |
|
Tair (Enterprise Edition) otimizada para memória persistente |
Todas as versões |
|
Tair (Enterprise Edition) baseada em disco |
Todas as versões |
Antes de dimensionar
Requisitos do cliente
Configure seu cliente para lidar com os seguintes comportamentos antes de iniciar uma operação de dimensionamento:
|
Modo de conexão |
Comportamento esperado |
|
Modo de conexão direta |
O cliente deve processar corretamente o comando |
|
Modo proxy |
Alguns nós de proxy são liberados durante a redução de escala, o que causa queda nas conexões. O cliente deve se reconectar automaticamente. |
|
Durante o dimensionamento (qualquer modo) |
Alta latência pode causar tempos limite de comandos. O cliente deve se reconectar automaticamente após um tempo limite. |
Utilize um cliente recomendado para evitar problemas de compatibilidade.
Comportamento de comandos especiais
Evite usar os seguintes tipos de comandos durante uma operação de dimensionamento:
|
Tipo de comando |
Comportamento durante o dimensionamento |
|
Comandos de bloqueio |
Podem causar erros. |
|
Comandos Pub/Sub |
Não garantem consistência de dados e podem gerar erros, dependendo da implementação do cliente. |