A entrevista não é nada difícil: análise do modo Redis Cluster, slot hash, alta disponibilidade do modo Cluster, consistência, JedisPool do cliente, expansão do cluster

1 A diferença entre o modo Cluster e o modo mestre-escravo

• No modo mestre-escravo, o nó mestre / escravo contém a quantidade total de dados em cache (o gargalo de expansão será encontrado quando a quantidade de dados for grande)
• No modo de cluster de cluster, os dados de cache completos são espalhados em vários nós e cada nó contém apenas uma parte dos dados de cache completos.

2 Divisão de dados do nó no modo de cluster

Os dados são divididos de acordo com o slot hash.

O cluster Redis tem 16384 slots de hash e cada chave é verificada pelo CRC16 e módulo 16384 para determinar a qual slot a chave corresponde.

Por exemplo, o cluster atual tem 3 nós, então:

1. O nó A contém slots de hash 0 a 5500
2. O nó B contém slots de hash 5501 a 11000
3. O nó C contém slots de hash 11001 a 16384

3 O modo de cluster requer pelo menos três nós mestres

1. Como o modo Cluster é baseado no protocolo Gossip para sincronizar o estado do cluster, é um modo completamente descentralizado.
2. Portanto, a fim de atingir a consistência do estado do cluster, é necessário seguir o princípio da "maioria" (por exemplo, um nó falha repentinamente ao se conectar, e apenas a maioria dos nós pensa que não pode ser conectado realmente não é conectado)
3. Portanto, pelo menos 3 nós são necessários
   1. No cenário de votação distribuída, um cluster de 3 nós pode tolerar um ponto de suspensão de nó
   2. O Redis tem uma configuração cluster-require-full-verification = no, mesmo se um nó mestre estiver inativo, outros nós mestres ainda podem fornecer serviços (= sim, enquanto um nó mestre estiver inativo, o cluster não estará disponível)

4 Cluster de modo de cluster alta disponibilidade

Para garantir a alta disponibilidade dos nós, geralmente é adotado o modo mestre-escravo, sendo que cada nó mestre possui nós escravos.

Portanto, o cluster está altamente disponível no modo Cluster e requer 3 mestres e 3 escravos.

5 Operação de tecla única no modo de cluster

5.1 Operação redis-cli simples do cliente

redis 127.0.0.1:7000> set foo bar
-> Redirected to slot [12182] located at 127.0.0.1:7002
OK

• Se o slot correspondente à chave da operação atual não estiver no nó ao qual o cliente atual está conectado, o cluster retornará um erro MOVED e indicará o nó de destino correto
• Em seguida, o cliente continua a enviar solicitações para o nó de destino correto

5.1.1 Por que o cliente executa o redirecionamento em vez do servidor para ajudar a encaminhar a operação para o nó correto?

acho:

Se o servidor ajudar a encaminhar a operação para o nó correto:

• O servidor será bloqueado (por causa do processamento de thread único das solicitações do cliente), o segundo plano encaminhará a operação para outros servidores e aguardará o resultado
• Todo o processo envolve 4 transmissões de rede (o mesmo número de transmissões de rede que o método de redirecionamento do cliente)

Se for redirecionamento do cliente:

• O servidor não bloqueia, após retornar o comando de redirecionamento, continua a processar outras solicitações do cliente
• Redirecionamento do cliente, todo o processo envolve 4 transmissões de rede (o mesmo que o número de operações de encaminhamento do servidor)

Em contraste, o redirecionamento do cliente é mais acessível.

5.2 Operações em Java JedisPool

Há um problema no modo redis-cli do cliente simples: é impossível saber com antecedência em qual nó está o slot correspondente à chave atual, portanto, muitos redirecionamentos serão gerados.

JedisPool é um pool de conexão Java redis. Ele armazena em cache o relacionamento correspondente de <slot, node>. Portanto, ao realizar as operações, calcule primeiro o slot correspondente à chave e, em seguida, encontre o nó correspondente ao slot.

6 Operação de teclas múltiplas no modo de cluster

Como várias chaves podem corresponder a vários slots, e vários slots são distribuídos em nós diferentes, o modo Cluster geralmente não oferece suporte a operações relacionadas a várias chaves.

// 以 Java Redis 客户端 Jedis 为例：
// 对于 multi keys，要求所有的 key 都对应同一个 slot 才能执行（这个限制更严格，更宽松一点的限制是：可以对应多个 slot，但这些slot 都在一个节点上）
if (keys.length > 1) {
    
    
  int slot = JedisClusterCRC16.getSlot(keys[0]);
  for (int i = 1; i < keyCount; i++) {
    
    
    int nextSlot = JedisClusterCRC16.getSlot(keys[i]); // 计算key对应的 slot
    if (slot != nextSlot) {
    
     // slot 不一致则抛异常
      throw new JedisClusterException("No way to dispatch this command to Redis Cluster "
          + "because keys have different slots.");
    }
  }
}

6.2 Use hash tag para controlar o slot correspondente à chave

Em alguns cenários, esperamos que várias chaves estejam em um nó. Como controlá-lo?

• redis fornece hash tag chave
• Valor-chave {hash tag}
• Se a chave tiver uma hashtag, a hash tag é usada no cálculo do CRC16, não a chave específica
• Portanto, se você quiser que várias chaves estejam no mesmo nó (mesmo slot), você pode fazer com que várias chaves usem a mesma hashtag

7 consistência não forte

o motivo:

1. Sincronização mestre-escravo.
   1. É executado de forma assíncrona, pode acontecer que a escrita ainda não esteja sincronizada, mas o master trava e a escrita é perdida neste momento.
2. Comutação mestre-escravo da partição de rede.
   1. As partições de rede aparecem no modo de cluster. Se os nós mestre e escravo estiverem em partições diferentes, e um dos nós escravos da partição for selecionado como mestre, é possível que parte da operação de gravação do nó mestre original não tenha sido sincronizado com o escravo devido à partição da rede.

假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点。 
其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点。
还有一个客户端 Z1 。

假设集群中发生网络分区，那么集群可能会分为两方，
大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，
小部分的一方则包含节点 B 和客户端 Z1 。
Z1仍然能够向主节点B中写入, 
如果网络分区发生时间较短,那么集群将会继续正常运作,
如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了。

8 Expansão / resharding do cluster de cluster

Adicionar nós, excluir nós e fragmentar novamente são essencialmente um tipo de operação: migração de slot.

Por exemplo, se um novo nó for adicionado, alguns slots em outros nós serão alocados para o novo nó.

No modo Cluster, a unidade básica de migração de dados é o slot.

Migração de 8,1 slots

Etapas de migração de slot:

1. Marque o slot como um estado de transição intermediário (conforme mostrado na figura acima, se você sair do nó A, então o slot marcado em A está migrando estado, e se você mover para o nó B, marcar slot em B é o estado de importação )
2. Migre um por um de acordo com a chave no slot, bloqueando a migração de forma síncrona
   1. A envia uma chave no slot para B
   2. B Após receber os dados, salve-os localmente e responda OK
   3. Depois de receber a resposta OK, exclua a chave local
3. Recuperável após o processo de migração ser desconectado

8.2 Processamento da solicitação do cliente durante a migração do slot

Devido ao processo de migração do slot, parte da chave no slot está no nó A e parte no nó B, portanto, o processamento da solicitação do cliente mudará muito.

1. O cliente visita primeiro o nó antigo correspondente ao slot
2. Se os dados ainda estão no nó antigo, o nó antigo é processado normalmente
3. Se os dados não estiverem mais no nó antigo, o nó antigo retorna a ordem de redirecionamento ask B para o cliente
4. O cliente executa a pergunta B primeiro
5. O cliente então executa a operação get

Por que não posso usar get diretamente ao redirecionar, mas emitir um comando ask primeiro?

Como o slot não pertence ao nó B (ainda pertence ao nó A), envie o comando get diretamente e B redirecionará o cliente para A, causando um redirecionamento circular