Mecanismo de compartilhamento de dados do cluster Redis Cluster

Introdução ao Redis Cluster

O Redis Cluster é a solução distribuída da Redis, lançada oficialmente na versão 3.0, que efetivamente solucionava as necessidades distribuídas da Redis.

O Redis Cluster geralmente é composto de vários nós.O número de nós deve ser pelo menos 6 para garantir um cluster completo e altamente disponível, três dos quais são nós principais e três são escravos. Os três nós principais alocam slots para lidar com as solicitações de comando do cliente, e os nós escravos podem ser usados para substituir o nó principal após a falha do nó principal.

Conforme mostrado na figura acima, o cluster contém 6 nós Redis, 3 mestres e 3 escravos, ou seja, M1, M2, M3, S1, S2, S3. Além da replicação de dados entre os nós Redis mestre e escravo, todos os nós Redis usam o protocolo Gossip para se comunicar, trocar e manter informações de metadados do nó.

De um modo geral, o nó Redis mestre manipulará as operações de leitura e gravação dos Clientes, enquanto o nó escravo manipulará apenas a operação de leitura.

Estratégia de compartilhamento de dados

O ponto mais importante na solução de armazenamento de dados distribuídos é o sharding de dados, também conhecido como sharding.

Para permitir que o cluster seja dimensionado horizontalmente, o primeiro problema a ser resolvido é como distribuir todo o conjunto de dados em vários nós de acordo com certas regras.Os métodos comuns de compartilhamento de dados incluem: compartilhamento de intervalo, compartilhamento de hash e hash consistente Algoritmos e slots de hash virtual.

O sharding de intervalo pressupõe que o conjunto de dados está ordenado e coloca os dados em ordem aproximada, podendo suportar bem a operação transversal. A desvantagem do sharding de intervalo é que existem pontos quentes ao escrever sequencialmente. Por exemplo, a gravação do tipo de log, a ordem do log geral está relacionada ao tempo e o tempo aumenta monotonicamente, portanto, o hot spot da gravação está sempre no último fragmento.

Para bancos de dados relacionais, devido à necessidade frequente de varreduras de tabela ou indexação, use basicamente uma variedade de estratégias de sharding.

O Redis Cluster usa particionamento de slot de hash virtual.Todas as chaves são mapeadas para slots inteiros de 0 a 16383 de acordo com a função hash.A fórmula de cálculo é slot = CRC16 (chave) & 16383. Cada nó é responsável por manter uma parte dos slots e os dados do valor-chave mapeados pelos slots.

Recursos da partição de slot virtual Redis:

A dissociação do relacionamento entre dados e nós simplifica a dificuldade de expansão e contração do nó.
O próprio nó mantém o relacionamento de mapeamento de slot e não requer que o serviço de cliente ou proxy mantenha os metadados da partição de slot
Suporte à consulta de mapeamento entre nós, slots e chaves, usados para roteamento de dados, dimensionamento de cluster online e outros cenários.

O cluster Redis fornece soluções flexíveis de expansão e contração de nós. Sem afetar os serviços externos do cluster, você pode adicionar nós ao cluster para expandir a capacidade ou ficar offline para reduzir a capacidade. Pode-se dizer que um slot é a unidade básica dos dados de gerenciamento de cluster Redis , e a escala do cluster é o movimento de slots e dados entre os nós.

Vamos primeiro olhar para o princípio da escala de cluster Redis. Entenda como garantir que o cluster esteja disponível durante o processo de migração de dados dos nós Redis ou quando a falha for recuperada.

Cluster de expansão

Para permitir que os leitores entendam melhor a operação de expansão de capacidade ao ficar online, usamos os comandos Redis Cluster para simular todo o processo.

Quando um novo nó Redis está em execução e ingressando em um cluster existente, precisamos migrar slots e dados para ele. Primeiro, você deve especificar um plano de migração para os novos nós para garantir que cada nó seja responsável por um número semelhante de slots após a migração, para garantir dados uniformes para esses nós.

1) Inicie primeiro um nó Redis, indicado como M4.
2) Use o comando meet do cluster para adicionar o novo nó Redis ao cluster. No início, o novo nó está no estado do nó mestre.Como não há slot responsável, ele não pode aceitar nenhuma operação de leitura e gravação.Vamos migrar o slot e preencher os dados para ele posteriormente.
3) Envie o comando setslot do cluster {slot} importando {sourceNodeId} ao nó M4 para preparar o nó de destino para importar os dados do slot. > 4) Envie o comando do slot de conjunto de cluster {slot} migrando {targetNodeId} para o nó de origem, ou seja, os nós M1, M2 e M3, para que o ponto do nó de origem esteja pronto para sair dos dados do slot.
5) O nó de origem executa o comando getkeysinslot {slot} {count} do cluster para obter as chaves de contagem pertencentes ao slot {slot} e, em seguida, executa a operação da etapa> 6 para migrar os dados do valor da chave.
6) Execute o comando migrate {targetNodeIp} "" 0 {timeout} keys {key ...} no nó de origem para migrar as chaves adquiridas para o nó de destino em lotes através do mecanismo de pipeline> a versão de migração em lote do comando migrate está no Redis 3.0 Disponível em 6 e acima.
7) Repita as etapas 5 e 6 até que todos os dados do valor-chave no slot sejam migrados para o nó de destino.
8) Envie o comando do conjunto de conjuntos de cluster {slot} nó {targetNodeId} a todos os nós principais no cluster para notificar o slot a ser alocado para o nó de destino. Para garantir que as alterações de mapeamento dos nós do slot sejam propagadas em tempo hábil, é necessário percorrer e enviar todos os nós principais para atualizar os slots migrados para executar o novo nó.

Encolher cluster

Reduzir o nó é colocar o nó Redis offline. Todo o processo requer o seguinte processo operacional.

1) Antes de tudo, é necessário confirmar se o nó offline possui um slot responsável.Se for, mova o slot para outro nó para garantir a integridade do mapeamento do nó de todo o slot do cluster após o nó ficar offline.
2) Quando o nó offline não é mais responsável pelo slot ou é um nó escravo, ele pode notificar outros nós no cluster para esquecer o nó offline e todos os nós podem ser desligados normalmente depois de esquecer de alterar o nó.

Os nós off-line precisam migrar seus próprios slots para outros nós; o princípio é o mesmo que o processo de expansão de nós anterior do slot de migração.

Após migrar o slot, você também precisará notificar todos os nós no cluster que você esqueceu de ficar offline, o que significa que outros nós não trocarão mais mensagens de fofoca com os nós que ficarão offline.

O cluster Redis usa o comando cluster forget {downNodeId} para adicionar o nó especificado à lista proibida Os nós na lista proibida não enviam mais mensagens de fofoca.

Roteamento do cliente

No modo de cluster, o nó Redis calcula primeiro o slot correspondente à chave ao receber comandos relacionados à chave e, em seguida, localiza o nó correspondente de acordo com o slot.Se o nó for ele próprio, processa o comando key; caso contrário, ele retorna um erro de redirecionamento MOVIDO e notifica o cliente Solicite o nó correto. Esse processo é chamado de redirecionamento MOVIDO.

Deve-se observar que o Redis não calcula simplesmente o conteúdo da chave ao calcular o slot.Quando o valor da chave inclui colchetes, apenas o conteúdo entre colchetes é calculado. Por exemplo, quando a chave é usuário: {10000}: books, apenas 10000 é calculado para o valor do hash.

O exemplo de erro MOVED exibe as seguintes informações, o slot de hash ao qual a chave x pertence é 3999 e o número de IP e da porta do nó responsável pelo processamento desse slot é 127.0.0.1:6381. O cliente precisa enviar uma solicitação de comando GET para o nó ao qual pertence, com base nesse IP e número de porta.

 
           < 
           code  
           class="hljs"></ 
           code 
           >

Como o redirecionamento de solicitação aumentará a sobrecarga de E / S, essa não é uma maneira eficiente de usar clusters Redis, mas de usar clientes de cluster inteligentes. Ao manter o relacionamento de mapeamento entre slots e nós Redis internamente, o Smart Client pode realizar a pesquisa chave a nó localmente, garantindo assim a maximização da eficiência de IO, e o redirecionamento MOVED é responsável por ajudar o cliente a atualizar o relacionamento de mapeamento.

O cluster Redis suporta slots e dados de migração online para concluir o dimensionamento horizontal.Quando os dados correspondentes ao slot são migrados do nó de origem para o nó de destino, o cliente precisa executar uma migração inteligente para garantir que os comandos principais possam ser executados normalmente. Por exemplo, quando os dados do slot são migrados do nó de origem para o nó de destino, alguns dados podem aparecer no nó de origem e outra parte no nó de destino.

Portanto, com base na situação acima, o processo de execução do comando do cliente é o seguinte:

O cliente envia comandos para o nó de origem de acordo com o cache do slot local e, se houver uma correspondência de chave, ele será executado diretamente e retornará o resultado ao cliente.
Se o nó retornar um erro MOVED, atualize o mapeamento do slot local para o nó Redis e, em seguida, reinicie a solicitação.
Se os dados estiverem sendo migrados, o nó responderá com uma exceção de redirecionamento de ASK. O formato é o seguinte: (erro) PERGUNTE {slot} {targetIP}: {targetPort}

O cliente extrai as informações do nó de destino da exceção de redirecionamento ASK, envia um comando solicitante ao nó de destino para abrir o identificador de conexão do cliente e, em seguida, executa o comando key.

Embora o ASK e o MOVED controlem o redirecionamento do cliente, eles são essencialmente diferentes. O redirecionamento ASK indica que o cluster está passando pela migração de dados do slot. O cliente não pode saber quando a migração está concluída, portanto, pode ser apenas um redirecionamento temporário. O cliente não atualizará o cache de mapeamento do slot para o nó Redis. No entanto, o redirecionamento MOVED indica que o slot correspondente à chave foi atribuído explicitamente ao novo nó, portanto, o cache de mapeamento do slot para o nó Redis precisa ser atualizado.

Failover

Quando um pequeno número de nós no cluster Redis falha, o failover automático é usado para garantir que o cluster possa fornecer serviços para o mundo externo normalmente.

Quando um nó Redis fica offline objetivamente, o cluster Redis escolhe um dos nós escravos para substituí-lo, de modo a garantir a alta disponibilidade do cluster. Este conteúdo não é o conteúdo principal deste artigo, os alunos interessados podem aprender por si mesmos.

No entanto, uma coisa a observar. Por padrão, quando qualquer um dos slots 16384 do cluster não está atribuído a um nó, o cluster inteiro fica indisponível. A execução de qualquer comando de chave retorna o comando CLUSTERDOWN Hash slot não servido. Quando o nó principal que está no slot fica offline, o cluster inteiro fica indisponível, desde a descoberta de falhas até a conclusão automática da transferência.Para a maioria das empresas, essa situação é insuportável, portanto, é recomendável configurar o parâmetro cluster-require-full-cover para no. Quando o nó principal falha, ele afeta apenas a execução de comandos relacionados do slot pelo qual é responsável e não afeta a disponibilidade de outros nós principais.