No Redis, se a biblioteca escrava falhar, o cliente pode continuar enviando mensagens para a biblioteca mestre e outras bibliotecas escravas para operações relacionadas. No entanto, se a biblioteca principal falhar, isso afetará diretamente a operação de sincronização da biblioteca escrava (a biblioteca escrava não possui uma biblioteca principal correspondente para executar operações de replicação de dados relacionadas) e não há instância para dar suporte ao cliente para executar operações de gravação .

Mudar a biblioteca escrava para a biblioteca principal precisa envolver três questões:

A biblioteca principal está realmente inoperante?
Qual biblioteca escrava deve ser selecionada para alternar para a biblioteca mestre?
Como notificar a biblioteca escrava e o cliente sobre as informações da nova biblioteca mestre?

1. O fluxo básico do mecanismo sentinela

O mecanismo sentinela está em execução quando a instância da biblioteca mestre-escravo está em execução. O principal comportamento do mecanismo sentinela é o monitoramento.

1.1 Monitoramento sentinela:

Durante o processo de execução, o processo sentinela enviará periodicamente comandos PING para todas as bibliotecas master-slave para verificar se elas ainda estão em execução online. Se a biblioteca escrava não responder ao comando PING do sentinela dentro do tempo especificado, o sentinela irá marcá-la como "status offline". Da mesma forma, se a biblioteca principal não responder ao comando PING do sentinela dentro do tempo especificado, o sentinela também marcará a biblioteca principal como "status offline" e iniciará o processo de troca automática da biblioteca principal .

1.2 Alternar automaticamente o processo da biblioteca principal

Este processo realiza primeiro a segunda tarefa da sentinela: a eleição do mestre. Depois que a biblioteca principal desliga, o Sentinel precisa selecionar uma instância da biblioteca escrava de muitas bibliotecas escravas de acordo com determinadas regras e usá-la como a biblioteca principal atualizada. Depois que essa etapa for concluída, haverá uma nova biblioteca mestre no cluster.
Em seguida, vem a última tarefa: notificações . Ao executar a notificação de tarefa, o sentinela irá enviar as informações da nova biblioteca principal para todas as outras bibliotecas escravas, deixá-las executar o comando replicaof, estabelecer uma conexão com a nova biblioteca principal e realizar a replicação dos dados. Ao mesmo tempo, o Sentinel enviará as informações de conexão da nova biblioteca principal para o cliente, permitindo que ele envie novas solicitações para a nova biblioteca principal.

Dentre essas três tarefas, a tarefa de notificação é relativamente simples, basta enviar as informações da nova biblioteca principal para a biblioteca escrava e para o cliente, e deixá-los se conectar com a nova biblioteca principal, sem nenhuma lógica de decisão envolvida. Mas nas duas tarefas de monitoramento e seleção do líder, a sentinela precisa tomar duas decisões:

Na tarefa de monitoramento, o Sentinel precisa decidir se a biblioteca principal está offline
Na tarefa de seleção mestre, o Sentinel também decide qual instância da biblioteca escrava escolher como a nova biblioteca mestre.

Como julgar se o banco de dados principal está offline?

2. Julgando se o banco de dados principal está offline

Se o banco de dados principal está offline é julgado em dois tipos: "offline subjetivo" e "offline objetivo".

2.1. Off-line subjetivo

Offline subjetivo: O mecanismo sentinela enviará um comando PING para a biblioteca mestre-escravo para detectar a conexão de rede entre ela e a biblioteca mestre-escravo para julgar o status da instância. Se o sentinela descobrir que o tempo de resposta da biblioteca mestre-escravo expirou, ele marcará a biblioteca mestre-escravo como "offline subjetiva".

erro de julgamento

Mas haverá uma situação em que o sentinela julgou mal que a biblioteca mestre-escravo não falhou e a biblioteca mestre não ficou offline. O sentinela julgou mal que estava offline. O erro de julgamento geralmente ocorre quando a pressão na rede do cluster é alta, a rede está congestionada ou a própria biblioteca principal está sob alta pressão .

Uma vez que o sentinela julgue que o banco de dados mestre está offline, ele precisa executar uma série de operações, como eleição de mestre e sincronização de banco de dados mestre-escravo, o que aumentará a sobrecarga adicional de computação e comunicação.

Portanto, é necessário reduzir o erro de julgamento.

Como reduzir erros de julgamento?

Apresente mais alguns sentinelas para negociação e julgamento, ou seja, agrupamentos de sentinelas.

Agrupamento Sentinela

Sentinel Cluster: Normalmente implementado em modo de cluster consistindo em várias instâncias. Apresente várias instâncias de sentinela para julgamento, evitando a situação em que uma única sentinela julga erroneamente que a biblioteca principal está offline devido a uma rede ruim. A probabilidade de várias redes sentinelas serem instáveis ao mesmo tempo é pequena, e a probabilidade de erro de julgamento também é pequena.

2.2 Objetivo off-line

Ao julgar se a biblioteca principal está off-line, um sentinela não pode ter a palavra final. A maioria dos sentinelas deve julgar que a biblioteca principal está "subjetivamente off-line" e a biblioteca principal será marcada como "objetivamente off-line". Essa declaração mostra que o biblioteca principal Ficar offline tornou-se um fato objetivo, e o princípio do julgamento é: a minoria obedece à maioria.

Objetivo off-line: quando há N clusters, quando há N/2+1 clusters que julgaram o banco de dados principal como "subjetivamente off-line", o banco de dados principal pode ser finalmente julgado como "objetivamente off-line". Reduza a sobrecarga de alternância de biblioteca mestre-escravo causada por erros de julgamento. (Existem vários exemplos para fazer o julgamento de "offline subjetivo" da biblioteca principal, que é definido pelo administrador do Redis com confiança).

3. Mecanismo de comutação mestre-escravo: a comutação mestre-escravo será realizada quando a biblioteca principal estiver offline

Como escolher uma nova biblioteca principal?

De um modo geral, o processo de seleção de uma nova biblioteca principal do Sentinel pode ser chamado de "triagem + pontuação". É para remover bibliotecas escravas não qualificadas de acordo com certas condições de triagem em várias bibliotecas escravas de instância . Então, de acordo com certas regras , pontue as bibliotecas escravas restantes uma a uma e selecione a biblioteca escrava com a pontuação mais alta como a nova biblioteca mestre.

3.1 Condições de triagem

Não é apenas necessário julgar o status atual da biblioteca escrava, mas também seu status de conexão de rede anterior . Se o número de desconexões entre a biblioteca escrava e a biblioteca mestre exceder o limite, há um motivo para detalhar que o status da conexão de rede da biblioteca escrava não é muito bom e pode ser filtrado. Embora esteja funcionando agora, se for cortado depois de um tempo, o proprietário precisa ser reeleito, então é necessário julgar seu estado anterior.

Como julgar?

Use o item de configuração down-after-milliseconds*10. Dentre eles, down-after-milisseconds é o tempo máximo que consideramos estar desconectado do banco de dados. Se dentro de milissegundos após milissegundos, os nós mestre e escravo não estiverem conectados à rede, o banco de dados escravo será considerado desconectado. Se o tempo de desconexão exceder 10 vezes, considera-se que a transição de rede da biblioteca escrava não é muito boa e não é adequada para a biblioteca mestre.

3.2 Regras de pontuação

Pode ser pontuado de acordo com três regras: prioridade da biblioteca escrava, progresso da cópia da biblioteca escrava e número de identificação da biblioteca escrava

Basta ter a maior pontuação em uma determinada rodada, então ele é o novo mestre, e o processo de seleção do mestre está encerrado.Se não houver pontuação máxima, a próxima rodada será realizada.

A primeira rodada: a biblioteca escrava com a prioridade escrava de maior prioridade tem uma pontuação mais alta

Os usuários podem definir diferentes prioridades para diferentes bibliotecas escravas por meio do item de configuração de prioridade escrava. Por exemplo, você tem duas bibliotecas escravas com grande capacidade de memória

A diferença é que você pode definir manualmente uma alta prioridade para instâncias com muita memória. Ao selecionar o mestre, o Sentinel dará notas altas para a biblioteca escravo com alta prioridade. Se houver uma biblioteca escravo com a prioridade mais alta, será a nova biblioteca mestre. Se as prioridades das bibliotecas escravas forem as mesmas, o sentinela inicia a segunda rodada de pontuação.

A segunda rodada: a biblioteca escrava com o grau de sincronização mais próximo da antiga biblioteca mestre tem uma pontuação alta

Se você escolher a biblioteca escrava mais próxima da antiga biblioteca mestre como a biblioteca mestre, a nova biblioteca mestre terá os dados mais recentes.

Como julgar o progresso da sincronização da biblioteca escrava e da biblioteca mestre? (copiar progresso)

Quando a biblioteca master-slave é sincronizada, há um processo de propagação de comando. Nesse processo, a biblioteca master usará master-repl-offset para gravar, e a última operação de gravação atual está na posição intermediária de repl-backlog- buffer, enquanto a biblioteca slave usará slave -repl-offset registra o progresso da replicação.

Portanto, precisamos encontrar a biblioteca slave mais próxima de master-repl-offset e slave-repl-offset. Se a pontuação for alta, ela será selecionada como a nova biblioteca principal. Se o deslocamento de repetição do escravo for o mesmo, a próxima rodada de pontuação será executada.

Conforme mostrado na figura abaixo, o master_repl_offset da antiga biblioteca master é 1000, e o slave_repl_offset das bibliotecas slave 1, 2 e 3 são 950, 990 e 900, respectivamente. Então, a biblioteca slave 2 deve ser selecionada como a nova biblioteca principal.

A terceira rodada: aquele com o menor número de ID obtém a pontuação mais alta do pool

Cada instância terá um id, que é semelhante ao número da biblioteca escrava. Quando o Redis seleciona o mestre, existe uma regra: no caso de mesma prioridade e andamento da replicação, quanto menor o ID, maior a pontuação.

3.3 Resumo da comutação mestre-escravo

Em primeiro lugar, o mecanismo sentinela filtrará algumas bibliotecas escravas que não atendem aos requisitos de acordo com o status online e o status da rede. Em seguida, pontue a biblioteca escrava de acordo com a prioridade, o progresso da replicação e o tamanho do ID, e aquela com a pontuação mais alta é selecionada como a nova biblioteca mestre.

4. Resumo do mecanismo sentinela

A sincronização de dados do cluster mestre-escravo garante a confiabilidade dos dados. Quando a biblioteca principal falha, a comutação automática mestre-escravo é o principal suporte para serviço ininterrupto.

O mecanismo sentinela do Redis conclui automaticamente as três funções a seguir, realizando assim a comutação automática da biblioteca mestre-escravo, o que pode reduzir a sobrecarga de operação e manutenção do cluster Redis:

Monitore o status de execução da biblioteca principal e avalie se a biblioteca principal está objetivamente offline;
Depois que a biblioteca principal ficar off-line objetivamente, selecione uma nova biblioteca principal;
Após a seleção da nova biblioteca mestre, a biblioteca escrava e o cliente são notificados.

A fim de reduzir a taxa de erros de julgamento, em aplicações práticas, o mecanismo sentinela é geralmente implantado em várias instâncias. Várias instâncias sentinelas usam o princípio de "a minoria obedece à maioria" para julgar se o banco de dados principal está objetivamente offline. De um modo geral, podemos implantar três sentinelas.Se duas sentinelas determinarem que a biblioteca principal está "subjetivamente off-line", o processo de troca pode ser iniciado. Claro, se você quiser melhorar ainda mais a precisão do julgamento, também pode aumentar o número de sentinelas adequadamente, por exemplo, usar cinco sentinelas.

O que devo fazer se uma instância no cluster sentinela estiver inoperante? Isso afetará o julgamento do status do banco de dados principal e a eleição do mestre?

Basta colocar a conclusão: quando há nós defeituosos, desde que a maioria dos nós no cluster esteja em estado normal, o cluster ainda pode fornecer serviços para o mundo externo

A maioria das instâncias do cluster sentinela chega a um consenso e, após julgar que a biblioteca principal está "objetivamente offline", qual instância executará a troca mestre-escravo?

Depois que o cluster sentinela julgar que a biblioteca principal está "subjetivamente off-line", ele elegerá um "líder sentinela" e, em seguida, concluirá a troca mestre-escravo em todo o processo.

Durante o processo de troca mestre-escravo do Sentinel, o cliente pode executar normalmente a operação de solicitação?

Se o cliente usar a separação leitura-gravação, a solicitação de leitura poderá ser executada normalmente na biblioteca escrava sem ser afetada. No entanto, como a biblioteca principal foi desligada neste momento e o sentinela ainda não selecionou uma nova biblioteca principal, a solicitação de gravação falhará durante esse período e a duração da falha = o momento em que o sentinela troca o mestre -slave + o cliente percebe o novo horário da biblioteca principal.

Se você não quiser que a empresa esteja ciente da exceção, o cliente pode apenas armazenar em cache as solicitações com falha de gravação ou gravá-las no middleware da fila de mensagens e enviar essas solicitações de gravação para a nova biblioteca mestre depois que o sentinela alternar o mestre -slave. Este cenário é adequado apenas para negócios que não são sensíveis ao valor de retorno da solicitação de gravação e também precisa ser adaptado pela camada de negócios. Além disso, se a alternância mestre-escravo demorar muito, também será causar muitas solicitações de gravação no cache do cliente ou no middleware da fila de mensagens. Leva mais tempo para reproduzir essas solicitações após a conclusão.

O sentinela detecta quanto tempo a biblioteca principal não responde antes de promover a biblioteca escrava para a nova biblioteca principal.Este tempo é configurável (parâmetro down-after-milisseconds). Quanto menor o tempo de configuração, mais sensível é o sentinela. O cluster sentinela iniciará uma alternância mestre-escravo se a biblioteca principal não puder ser conectada em um curto período de tempo. Essa configuração provavelmente causará comutação desnecessária devido ao congestionamento da rede, mas a biblioteca principal é normal. Claro, quando a biblioteca principal realmente falha, devido à transição oportuna, o impacto nos negócios é mínimo. Se o tempo de configuração for maior, mais conservador será o sentinela, o que pode reduzir a probabilidade de erro de julgamento por parte do sentinela. No entanto, quando a biblioteca principal falhar, o tempo para falha de gravação de negócios será maior e a quantidade de solicitação de gravação em cache os dados aumentarão.

2. A sentinela desliga

Se uma instância sentinela falhar durante o tempo de execução, a biblioteca mestre-escravo ainda poderá alternar normalmente?

Na verdade, uma vez que várias instâncias formam um cluster sentinela, mesmo que uma instância sentinela falhe e desligue, outras sentinelas podem continuar a cooperar para concluir o trabalho de alternar a biblioteca principal, incluindo determinar se a biblioteca principal está offline e selecionar uma nova biblioteca principal library e notificações de bibliotecas e clientes.

Se você implantou um cluster sentinela, saberá que, ao configurar as informações do sentinela, precisamos apenas usar o seguinte item de configuração para definir o IP principal e a porta e não configurar as informações de conexão de outros sentinelas.

sentinela monitor <nome-mestre> <ip> <redis-port> <quorum>

Já que as sentinelas não conhecem os endereços umas das outras, como elas formam um agrupamento de sentinelas?

1. Composição do cluster sentinela com base no mecanismo pub/sub

A razão pela qual os sentinelas podem ser descobertos uns pelos outros: o mecanismo de publicação/assinatura fornecido pelo Redis (mecanismo de publicação/assinatura)

1.1 Sentinelas são descobertas umas pelas outras:

Desde que o sentinela tenha estabelecido uma conexão com a biblioteca principal, ele pode publicar informações na biblioteca principal e publicar suas próprias informações de conexão (ip e número da porta). Ao mesmo tempo, você também pode assinar informações da biblioteca principal para obter informações de conexão publicadas por outros Sentinels. Quando vários Sentinels publicam e se inscrevem na biblioteca principal, eles conhecem o endereço IP e o número da porta uns dos outros.

Além das instâncias sentinela, os aplicativos escritos por nós também podem publicar e assinar mensagens por meio do Redis.

Como o Redis diferencia entre diferentes aplicativos?

Redis caminho através de canais. Classifique e gerencie mensagens para distinguir diferentes mensagens de aplicativos. Um canal é na verdade um tipo de mensagem. Quando os tipos de mensagem são iguais, eles pertencem a um canal. Somente aplicativos inscritos no mesmo canal podem trocar informações por meio de mensagens publicadas.

No cluster mestre-escravo, a biblioteca mestre tem um canal "__sentinel__:hello" e diferentes sentinelas podem descobrir e se comunicar uns com os outros implementando-o.

1.2 Instruções para troca de mensagens do Sentinel:

Por exemplo: Na figura abaixo, o Sentinel 1 publica seu próprio IP (17216.19.3) e porta 26579) no canal "_sentinel_:hello" e os Sentinel 2 e 3 se inscrevem nesse canal. Nesse momento, os Sentinel 2 e 3 podem obter diretamente o endereço IP e o número da porta do Sentinel 1 desse canal.

Em seguida, os Sentinels 2 e 3 podem estabelecer uma conexão de rede com o Sentinel 1. Dessa forma, os Sentinels 2 e 3 também podem estabelecer uma conexão de rede, para que um cluster do Sentinel seja formado. Eles podem se comunicar uns com os outros por meio de conexões de rede, como julgar e negociar se a biblioteca principal está offline

Além de estabelecer conexões entre si para formar um cluster, os Sentinels também precisam estabelecer conexões com bibliotecas escravas. Porque na tarefa de monitoramento do sentinela, o sentinela precisa fazer um julgamento de pulsação na biblioteca mestre-escravo e, após a conclusão da troca da biblioteca mestre-escravo, ele também precisa notificar a biblioteca escrava para sincronizá-la com a nova biblioteca mestre.

Como o Sentinel se conecta com a retomada da biblioteca escrava? Como saber o endereço IP e a porta da biblioteca escrava?

1.3 O Sentinel estabelece uma conexão com a biblioteca escrava: comando INFO

Quando o sentinela envia um comando INFO para a biblioteca principal, a biblioteca principal retornará a lista da biblioteca escrava para o sentinela após receber o comando. Após o Sentinel receber as informações de conexão da lista de bibliotecas secundárias, ele estabelecerá uma conexão com cada biblioteca secundária e monitorará continuamente a biblioteca secundária nesta conexão.

Através do mecanismo pub/sub, são estabelecidos clusters de sentinela entre sentinelas, e as informações de conexão da biblioteca escrava são obtidas enviando o comando INFO, e a sentinela estabelece uma conexão com a biblioteca escrava para monitoramento. Depois que a biblioteca mestre-escravo é trocada, o cliente precisa saber as informações de conexão da nova biblioteca mestre antes de enviar informações para a nova biblioteca mestre. Portanto, o sentinela também precisa concluir a tarefa de informar ao cliente sobre as novas informações da biblioteca principal.

Ao usar o Sentinel, às vezes encontramos um problema: Como monitorar o processo de troca mestre-escravo do Sentinel no lado do cliente? Por exemplo, em qual etapa a troca mestre-escravo progrediu? Isso é realmente um requisito, o cliente lado É possível obter vários eventos que ocorrem durante o processo de monitoramento, seleção mestre e comutação do cluster sentinela.

1.4 Sincronização de informações entre sentinela e cliente

1.5 Notificação de eventos do cliente com base no mecanismo pub/sub

Em essência, o Sentinel é uma instância do Redis rodando em um modo específico, mas não completa a operação de requisição de serviço, mas apenas completa as tarefas de monitoramento, eleição mestre e notificação. Portanto, cada instância do sentinela também fornece mecanismo de publicação/assinatura, os clientes podem assinar mensagens do sentinela . Existem muitos canais de assinatura de mensagens fornecidos pelo Sentinel, e diferentes canais contêm diferentes eventos-chave durante o processo de troca de biblioteca mestre-escravo

Eventos comuns:

evento	canal relacionado
Evento off-line da biblioteca principal	+sdown (a instância entra no estado "offline subjetivo")
	-sdown (a instância sai do estado "offline subjetivo")
	+odown (a instância entra no estado "objetivamente offline")
	-odown (a instância sai do estado "objetivamente offline")
Evento de reconfiguração do escravo	+slave-reconf-sent (sentinela envia o comando SLACEOF para reconfigurar a biblioteca escrava)
	+slave-reconf-inprog (configura a nova biblioteca principal da biblioteca, mas ainda não sincronizada)
	+slave-reconf-done (configurar a nova biblioteca principal da biblioteca e concluir a sincronização com a nova biblioteca principal)
Nova chave da biblioteca principal	+switch-master (mudança de endereço da biblioteca principal)

Conhecendo estes canais, os clientes podem subscrever as mensagens do Sentry. As etapas específicas da operação são que, depois que o cliente lê o arquivo de configuração do Sentinel, ele pode obter o endereço e a porta do Sentinel e estabelecer uma conexão de rede com o Sentinel. Em seguida, você pode executar o comando de assinatura no cliente para obter diferentes mensagens de evento.

Por exemplo, você pode executar o seguinte comando para se inscrever no "evento em que todas as instâncias entram no estado off-line objetivo":

inscreva-se +odown

Inscreva-se em todos os canais

PS INSCREVA-SE *

Quando o sentinela selecionar a nova biblioteca master, o cliente verá o seguinte evento switch-master. Este evento indica que a biblioteca principal foi trocada e o endereço IP e as informações de porta da nova biblioteca principal já estão disponíveis. Neste momento, o cliente pode usar o endereço e a porta da nova biblioteca principal para se comunicar.

switch-master <nome do mestre> <oldip><oldport> <newport>

Por meio da notificação de eventos, o cliente pode não apenas obter as informações de conexão da nova biblioteca mestre após a troca mestre-escravo, mas também monitorar e obter vários eventos importantes que ocorrem durante a troca mestre-escravo. Dessa forma, o cliente pode saber para qual etapa o mestre-escravo muda, o que ajuda a entender a velocidade de comutação.

Resumo: Com o mecanismo pub/sub, o Sentry pode estabelecer conexões com bibliotecas escravas, entre Sentinels e Sentinels e entre Sentinels e clientes. Julgando que a biblioteca principal está offline, as três tarefas de seleção mestre com base no monitoramento do cluster sentinela, eleição mestre e notificação podem basicamente funcionar normalmente.

Após a falha mestre-escravo, há várias instâncias no cluster, como determinar qual sentinela executará a troca mestre-escravo real?

2. Qual sentinela realiza a comutação mestre-escravo?

Na verdade, o processo de troca de mestre-escravo pelo qual o sentinela é na verdade um processo de "arbitragem de votação", assim como a eleição de mestre.

2.1 Partindo do processo principal de eleição do Sentinela:

Qualquer instância enviará o comando is-master-down-by-addr para outras instâncias, desde que julgue que a biblioteca mestre está "subjetivamente offline". Então, outras instâncias responderão com S ou N conforme sua conexão com a biblioteca principal, Y equivale a um voto a favor e N equivale a um voto negativo.

Uma vez que um sentinela tenha obtido o número de votos sim necessários para a arbitragem, ele pode marcar a biblioteca principal como "objetivamente offline". O número necessário de votos positivos é definido por meio do item de configuração de quorum no arquivo de configuração do sentinela. Por exemplo, agora existem 5 sentinelas e a configuração de quorum é 3. Então, uma sentinela precisa de 3 votos sim e a biblioteca principal pode ser marcada como "objetivamente offline". Os 3 votos sim incluem o voto sim do próprio sentinela e os outros dois votos sim do sentinela.

2.2 A sentinela elege o processo do Líder: Eleição do Líder

Neste ponto, a sentinela pode enviar comandos para outras sentinelas, indicando que deseja realizar a troca mestre-escravo sozinha, e deixar que todas as outras sentinelas votem. Este processo de votação é chamado de "Eleição de Líder". Como o sentinela que finalmente executa a troca mestre-escravo é chamado de Líder, o processo de votação é para determinar o Líder.

Durante o processo de votação, qualquer Sentinela que queira se tornar um Líder deve atender a duas condições: primeiro, obter mais da metade dos votos a favor; segundo, o número de votos que ele obtém deve ser maior ou igual ao valor do quórum no arquivo de configuração sentinela. Tome 3 sentinelas como exemplo, supondo que o quórum seja definido como 2 neste momento, então qualquer sentinela que queira se tornar um líder só precisa obter 2 votos sim.

Especificamente explicado através da figura a seguir:

Em T1, S1 julga que o banco de dados principal está "objetivamente offline", se quiser se tornar um líder, ele primeiro vota em si mesmo e depois envia comandos para S2 e S3 respectivamente, indicando que deseja se tornar um líder.

Em T2, S3 julga que o banco de dados principal está "objetivamente offline" e também deseja se tornar um líder, então ele vota primeiro em si mesmo e depois envia comandos para S1 e S2 respectivamente, indicando que deseja se tornar um líder.

No tempo T3, S1 recebe a solicitação de votação do Líder de S3. Como S1 votou em Y para si mesmo, não pode mais votar em outros sentinelas, então S1 responde N para expressar sua discordância. Ao mesmo tempo, S2 recebe a solicitação de votação do Líder enviada por S3 em T2. Como S2 não votou antes, ele responderá Y ao primeiro sentinela que enviou um pedido de voto e responderá N ao sentinela que enviou um pedido de voto posteriormente. Portanto, em T3, S2 responde a S3 e concorda que S3 se torne o líder .

Em T4, S2 recebe o comando de votação enviado por S1 em T1. Como S2 concordou com o pedido de votação de S3 em T3, neste momento, S2 responde N a S1, expressando sua desaprovação de S1 se tornar o líder. Isso acontece porque o tráfego de rede entre S3 e S2 é normal, mas o tráfego de rede entre S1 e S2 pode estar apenas congestionado, fazendo com que a solicitação de votação seja transmitida lentamente.

Finalmente, no tempo T5, S1 recebe um voto Y de si mesmo e um voto N de S2. Além de seu próprio voto Y, S3 também recebeu um voto Y de S2. Neste momento, o S3 não apenas obteve mais da metade dos votos do Líder, mas também atingiu o valor de quorum predefinido (o quorum é 2), então finalmente se tornou o Líder. Em seguida, o S3 começará a realizar a operação de seleção mestre e, após a seleção da nova biblioteca mestre, notificará outras bibliotecas escravas e clientes sobre as informações da nova biblioteca mestre.

Se S3 não obtiver 2 votos Y, essa rodada de votação não produzirá um Líder. O cluster do Sentinel aguardará um período de tempo (ou seja, o dobro do tempo limite de failover do Sentinel) antes da reeleição . Isso ocorre porque a votação bem-sucedida do cluster sentinela depende em grande parte da propagação normal da rede dos comandos eleitorais. Se a pressão da rede for alta ou houver congestionamento de curto prazo, pode fazer com que nenhum sentinela obtenha mais da metade dos votos a favor. Portanto, espere até que o congestionamento da rede melhore antes de votar, e a probabilidade de sucesso aumentará.

Deve-se notar que, se houver apenas 2 instâncias no cluster sentinela, neste momento, se uma sentinela quiser se tornar um líder, ela deverá obter 2 votos em vez de 1 voto. Portanto, se um sentinela desligar, o cluster neste momento não poderá executar a comutação de biblioteca mestre-escravo. Portanto, geralmente configuramos pelo menos 3 instâncias do Sentinel. Isso é muito importante e você não pode ignorá-lo em aplicações práticas.

Por que os Sentinelas não votam em si mesmos ao mesmo tempo?

Para que S1, S2 e S3 votem entre si ao mesmo tempo, é necessário que essas três sentinelas determinem que a biblioteca principal está objetivamente offline ao mesmo tempo. No entanto, as conexões de rede e as pressões do sistema de diferentes Sentinels não são exatamente as mesmas, e o tempo de recebimento da mensagem de negociação offline também pode ser diferente. Portanto, a probabilidade de eles fazerem um julgamento offline objetivo do banco de dados principal ao mesmo tempo é relativamente pequeno e geralmente há uma relação de sequência. O exemplo no artigo é que S1 e S3 são julgados primeiro e S2 não foi julgado.

Operações como a checagem online do status da biblioteca master-slave pelo sentinela são uma espécie de evento temporal, que é completado por um timer, geralmente estes eventos são executados a cada 100ms. Um pequeno deslocamento de tempo aleatório será adicionado ao ciclo de execução do cronômetro de cada sentinela. O objetivo é fazer com que o tempo para cada sentinela realizar as operações acima seja ligeiramente escalonado e também evitar que eles determinem simultaneamente que a biblioteca principal está off-line e elegendo ao mesmo tempo.Líder.

Redis tem 1 mestre e 4 escravos, 5 sentinelas e o quorum das sentinelas é 2. Se 3 sentinelas falharem, quando o banco de dados principal estiver inativo, os sentinelas podem julgar que o banco de dados principal está "objetivamente offline"? Ele pode alternar automaticamente?

1. O cluster sentinela pode determinar que o banco de dados principal está "subjetivamente off-line" . Como quorum=2, quando um sentinela julgar que o banco de dados principal está "subjetivamente off-line", obterá o mesmo resultado após perguntar a outro sentinela. O cluster sentinela pode determinar que a biblioteca principal está "objetivamente off-line".

2. No entanto, o Sentinel não pode concluir a alternância mestre-escravo . Depois que o sentinela marca o banco de dados principal "objetivamente offline", ao eleger o "líder sentinela", um sentinela deve obter mais do que a maioria dos votos (5/2+1=3 votos). Mas atualmente existem apenas 2 sentinelas vivas, não importa como você vote, uma sentinela só pode obter 2 votos no máximo e nunca alcançará o resultado da maioria dos votos.

Mais instâncias sentinelas são melhores?

Não, também vimos que o sentinela precisa se comunicar com outros nós e trocar informações quando julga "offline subjetivo" e elege o "líder sentinela" . Ao implantar vários Sentinelas, eles serão distribuídos em máquinas diferentes. Quanto mais nós houver são, maior o risco de falha da máquina. Esses problemas afetarão a comunicação e a eleição dos Sentinelas. Quando houver algum problema, significa que o tempo de eleição será maior. , o tempo para alternar mestre-escravo torna-se maior.
Quanto mais instâncias sentinela, menor será a taxa de erros de julgamento. No entanto, quando a biblioteca principal está offline e o líder é eleito, a instância precisa obter mais votos e o tempo de espera para que todas as sentinelas votem também pode aumentar O tempo para mudar da biblioteca também será mais longo e o cliente acumulará facilmente mais operações de solicitação, o que pode causar estouro de solicitação do cliente, resultando em perda de solicitação. Se a camada de negócios tiver requisitos de tempo de resposta para operações Redis, um alarme de tempo limite pode ocorrer porque a nova biblioteca principal não foi selecionada e a nova operação não pode ser executada.
Após o aumento de down-after-milisseconds, pode levar a tal situação: a biblioteca principal realmente falhou, mas demorou muito para o sentinela julgar, o que afetará a disponibilidade do Redis para negócios.

É benéfico reduzir os falsos positivos aumentando o valor para baixo após milissegundos?

É benéfico. Aumente adequadamente o valor de baixo após milissegundos. Quando houver flutuações de curto prazo na rede entre a sentinela e a biblioteca principal, a probabilidade de erro de julgamento pode ser reduzida . No entanto, aumentar o valor de inatividade após milissegundos também significa que o tempo de alternância mestre-escravo será maior e, quanto maior o impacto nos negócios, precisamos pesá-lo de acordo com o cenário real e definir um limite razoável.

3. Resumo: O mecanismo chave da sentinela (a sentinela contata a sentinela mestre-escravo convidada e o líder escolhe o mestre)

Quando resolvemos um problema do sistema, introduzimos um novo mecanismo ou projetamos uma camada de novas funções. O conteúdo principal da sentinela: Para realizar a troca mestre-escravo, introduzimos a sentinela; para evitar a falha de o comutador mestre-escravo após uma única sentinela falhar e, para reduzir a taxa de erro de julgamento, um cluster sentinela é introduzido; o cluster sentinela precisa de alguns mecanismos para suportar sua operação normal.

3.1 Estes mecanismos-chave do cluster sentinela:

Processo de formação de cluster sentinela baseado no mecanismo pub/sub;
Lista de escravos baseada no comando INFO, que pode ajudar o Sentinel e a biblioteca de escravos a estabelecer conexão;
Com base na própria funcionalidade de publicação/assinatura do Sentinel, isso permite a notificação de eventos entre clientes e o Sentinel.

Para comutação mestre-escravo, é claro, nem qualquer sentinela pode executá-lo se quiser, caso contrário, ficará confuso. Portanto, isso requer que o cluster sentinela eleja um Líder após julgar que a biblioteca principal está "objetivamente off-line" por meio de arbitragem de votação, e é responsável pela transição mestre-escravo real, ou seja, conclui a seleção da nova biblioteca mestre e notifica as bibliotecas escravas e clientes.

Finalmente, gostaria de compartilhar outra experiência com você: certifique-se de que as configurações de todas as instâncias sentinela sejam consistentes, especialmente o valor de julgamento de down-after-milisseconds para off-line subjetivo . Este valor é configurado de forma inconsistente em diferentes instâncias do Sentinel. Como resultado, o cluster do Sentinel não chegou a um consenso sobre a biblioteca principal com falha e não trocou a biblioteca principal a tempo. O resultado final é que o serviço de cluster está instável. Portanto, você não deve ignorar essa experiência aparentemente simples.

3. Resumo de todos os Sentinelas

1. Como o Sentinel se conecta à biblioteca principal

O Sentinel está diretamente associado à biblioteca principal, definido manualmente, você pode definir vários sentinelas

2. Como o sentinela envia mensagens para a biblioteca escrava?

O sentinela envia o comando info para a biblioteca master, a biblioteca master retorna a coleção slave da biblioteca slave, estabelece uma conexão com a biblioteca slave e envia as informações da nova biblioteca master para a biblioteca slave

3. Como a sentinela entra em contato com o cliente?

O cliente se inscreve em um canal do Sentinel, que é o mestre no canal, lê o arquivo de configuração do sentinela, obtém o endereço IP e o número da porta, estabelece uma conexão com o sentinela, assina as informações após a conexão, obtém as informações da biblioteca mestre e se comunica com o mestre A biblioteca estabelece uma conexão

Interpretação detalhada do mecanismo Redis Sentinel

1. Interpretação básica do mecanismo sentinela