A arquitetura padrão do Tair (compatível com Redis OSS) opera sem o modo cluster. Todos os dados ficam armazenados em um único shard, o que simplifica a operação, reduz custos e garante compatibilidade total com o protocolo Redis. Diferentemente da arquitetura cluster, a arquitetura padrão não permite ajustar a quantidade de shards e oferece os tipos de instância de alta disponibilidade (multirréplica) e nó único (réplica única).
e nó único (réplica única)
Tipos de arquitetura
Dois modos de implantação estão disponíveis: cloud-native e classic.
Arquitetura padrão cloud-native
Uma instância cloud-native suporta um nó mestre e até 9 nós de réplica. O nó mestre processa todas as cargas de trabalho de leitura e escrita. Os nós de réplica permanecem em standby ativo.
Quando um failover é acionado em várias zonas, o sistema tenta primeiro trocar dentro da mesma zona para evitar acessos entre zonas diferentes na sua aplicação.
Arquitetura padrão classic
Uma instância classic suporta um nó mestre e um nó de réplica. Em implantações multizona, o nó de réplica fica localizado na zona secundária.
Como funciona
A arquitetura padrão utiliza um modelo mestre-réplica. O nó mestre executa as cargas de trabalho diárias, enquanto os nós de réplica permanecem em standby ativo.
Se o nó mestre falhar, o sistema proprietário de alta disponibilidade (HA) detecta a falha e executa um failover:
O sistema HA identifica a falha no nó mestre (problema de I/O de disco, falha de CPU ou similar).
Um nó de réplica é promovido a novo nó mestre.
Todo o processo de failover é concluído em até 30 segundos.
Arquitetura padrão versus arquitetura cluster
|
Capacidade |
Arquitetura padrão |
Arquitetura cluster |
|
Distribuição de dados |
Shard único |
Múltiplos shards |
|
Ajuste de quantidade de shards |
Não suportado |
Suportado |
|
Réplicas de leitura |
Até 9 (cloud-native) |
Por shard |
|
Divisão de leitura e escrita |
Suportada |
Suportada |
|
Compatibilidade com protocolo Redis |
Total |
Parcial (comandos de múltiplas chaves restritos) |
|
QPS máximo recomendado |
100.000 |
Mais de 200.000 |
|
Caso de uso típico |
Cargas de trabalho estáveis em instância única |
Cargas de trabalho de alto throughput ou grande escala |
Recursos
Confiabilidade
Confiabilidade do serviço: Os nós mestre e de réplica rodam em hosts físicos separados. Caso o nó mestre apresente falha, o sistema HA proprietário realiza o failover automaticamente.
Confiabilidade dos dados: A persistência de dados vem ativada por padrão e todos os dados são gravados em disco. Há suporte a backup e restauração: clone ou reverta uma instância a partir de um conjunto de backups para se recuperar de operações acidentais. Instâncias em zonas com capacidades de recuperação de desastres (por exemplo, Hangzhou Zona H e Zona I) oferecem recuperação de desastres entre zonas.
Compatibilidade com o protocolo Redis
A arquitetura padrão é totalmente compatível com o protocolo Redis. Migre cargas de trabalho de um banco de dados Redis autogerenciado para uma instância padrão sem interrupção do serviço, utilizando o Alibaba Cloud Data Transmission Service (DTS) para migração incremental de dados.
Melhorias proprietárias de replicação
O mecanismo de replicação mestre-réplica da Alibaba Cloud resolve diversas limitações da replicação nativa do Redis:
|
Limitação do Redis nativo |
Como o Tair resolve |
|
A sincronização completa exige um fork, causando latência de milissegundos a segundos |
Replicação sem bloqueio: o problema do fork é resolvido, eliminando a latência induzida pela sincronização |
|
Falha no PSYNC dispara uma sincronização completa do Redis Database (RDB), consumindo I/O de disco e CPU |
Logs write-ahead (WALs) replicam dados entre nós; interrupções na replicação têm impacto mínimo no desempenho |
|
Processos filhos executando copy-on-write (COW) consomem memória do nó mestre, arriscando travamentos por falta de memória |
A pressão de memória causada pelo COW é eliminada |
|
Transferência de arquivos RDB na casa dos GB causa picos de tráfego de saída e I/O sequencial |
A replicação baseada em WAL evita transferências de arquivos grandes |
Quando usar a arquitetura padrão
QPS abaixo de 100.000 em uma única instância
O Redis nativo usa um modelo single-threaded. A arquitetura padrão atende à maioria das cargas de trabalho abaixo de 100.000 consultas por segundo (QPS). Se suas necessidades de QPS aumentarem, ative a divisão de leitura e escrita ou mude para a arquitetura cluster.
Necessidade de compatibilidade total com o protocolo Redis
Esta arquitetura suporta o protocolo Redis completo, incluindo comandos de múltiplas chaves restritos no modo cluster. Migre de um banco de dados Redis autogerenciado ou do Redis Sentinel sem modificar o código da aplicação.
Uso do Redis como armazenamento persistente
Persistência de dados, backup e restauração point-in-time são recursos nativos. Utilize backups para clonar uma instância ou reverter após alterações acidentais de dados.
Carga de trabalho com muitas leituras e poucos comandos de ordenação ou computação intensiva
Ative a divisão de leitura e escrita para escalar o throughput de leitura. Para cargas de ordenação ou computação intensivas de CPU em grande escala, prefira a arquitetura cluster.
Perguntas frequentes
Estou rodando Redis no modo Sentinel. Qual arquitetura devo escolher ao migrar para a nuvem?
Escolha a arquitetura padrão HA e ative o modo compatível com Sentinel na instância. Isso permite conectar-se ao Tair da mesma forma que você se conecta ao Redis Sentinel, sem exigir alterações no código da aplicação.
Minha instância tem 8 GB de memória com a arquitetura padrão. Como melhorar o desempenho sem aumentar a memória?
Duas opções estão disponíveis dependendo do seu gargalo:
Gargalo em conexões ou largura de banda: Ative a divisão de leitura e escrita. Essa opção não exige mudanças de código nem modificação de endpoint e pode ser desativada a qualquer momento. A instância roteia automaticamente as solicitações de leitura e escrita para os nós adequados.
Utilização de CPU consistentemente alta: Faça upgrade para uma instância cluster. Adicionar shards distribui a carga de CPU entre vários nós. Antes do upgrade, verifique a compatibilidade de comandos entre as arquiteturas padrão e cluster — consulte Limites de comandos suportados por instâncias cluster e instâncias com divisão de leitura e escrita.
A tabela a seguir compara o desempenho de uma instância Redis Open-Source Edition de 8 GB nas diferentes arquiteturas:
|
Arquitetura |
Memória (GB) |
Núcleos de CPU |
Largura de banda (Mbit/s) |
Conexões máximas |
Valor de referência de QPS |
|
Arquitetura padrão (nós mestre e de réplica) |
8 |
2 |
96 |
20.000 |
100.000 |
|
Arquitetura padrão (divisão de leitura e escrita ativada, um nó mestre, uma réplica de leitura) |
8 |
4 (2 × 2) |
192 (96 × 2) |
40.000 (20.000 × 2) |
200.000 |
|
Arquitetura cluster (2 shards) |
8 (4 GB × 2 shards) |
4 (2 × 2) |
192 (96 × 2) |
40.000 (20.000 × 2) |
200.000 |