Redis Cluster gère la défaillance du n?ud ma?tre par détection automatique, promotion des répliques et redirection du client. 1. Les n?uds détectent l'échec via le protocole de potins, marquant le n?ud comme PFAIL, puis échouez si la majorité des ma?tres sont d'accord. 2. 3. Le cluster ne rééquilibre pas automatiquement les emplacements ou ne remplace pas les répliques perdues, nécessitant une intervention manuelle. 4. Le basculement peut entra?ner une perte de données due à la réplication asynchrone, bien que des configurations telles que les replias à l'écriture puissent atténuer le risque.

Lorsqu'un cluster Redis s'exécute normalement, tous les n?uds (ma?tre et répliques) communiquent à l'aide du bus Redis Cluster. Si un n?ud ma?tre échoue, Redis Cluster dispose de mécanismes intégrés pour détecter l'échec, promouvoir une réplique pour devenir le nouveau ma?tre et redistribuer le trafic en conséquence.

Voici comment cela fonctionne plus en détail:

1. Détection de défaillance

Les n?uds de cluster Redis se cinglant constamment pour vérifier la santé. Si un n?ud ma?tre devient inaccessible (en raison d'un crash, d'une partition de réseau, etc.), d'autres n?uds le marquent comme PFAIL (échec possible). Après un certain temps, si suffisamment de n?uds sont d'accord, le statut change pour FAIL .

• Les n?uds utilisent un protocole de potins pour partager des informations.
• Au moins (N/2) 1 Les n?uds ma?tres doivent reconna?tre que le cluster de procéder avec le basculement.

Ce mécanisme empêche les faux positifs en raison de problèmes temporaires ou de hoquets de réseau court.

2. élections et basculement de réplique

Une fois qu'un ma?tre est marqué en FAIL , l'une de ses répliques est promue comme le nouveau ma?tre.

• Les répliques éligibles à la promotion sont celles qui ont réussi à reproduire les données récemment.
• Le cluster utilise un système de vote: les répliques demandent les votes d'autres n?uds, et le premier à obtenir suffisamment de votes gagne.
• Après la promotion, le nouveau ma?tre commence à accepter les écritures et le cluster met à jour son état interne.

Les clients connectés à l'ancien ma?tre seront automatiquement redirigés vers le nouveau ma?tre (s'ils prennent en charge le mode de cluster).

3. Rééquilibrage en grappes (pas immédiat)

Après le basculement, le cluster ne rééquilibre pas immédiatement les emplacements ou ne crée pas de nouvelles répliques. Cela signifie:

• S'il y avait plusieurs répliques auparavant, on peut maintenant manquer.
• La propriété de l'emplacement reste avec le nouveau ma?tre.
• Vous devrez ajouter manuellement une nouvelle réplique plus tard si vous le souhaitez.

Cela permet d'éviter les frais généraux inutiles lors de défaillances transitoires mais laisse la place à l'intervention humaine.

4. Qu'arrive-t-il aux données pendant le basculement?

Le cluster Redis utilise la réplication asynchrone par défaut, il y a donc de petites chances de perte de données pendant le basculement:

• Si le ma?tre avait accepté des écritures qui n'avaient pas encore été reproduites, ces changements peuvent être perdus.
• Pour réduire le risque, vous pouvez configurer Redis pour retarder les remerciements jusqu'à ce qu'une réplique confirme le réception (paramètre min-replicas-to-write ).

Pourtant, dans la plupart des configurations, le compromis entre la performance et la cohérence favorise ce modèle asynchrone.

C'est essentiellement la fa?on dont Redis Cluster gère une défaillance du n?ud ma?tre - détection, accord, promotion de répliques et redirection du client. Ce n'est pas infaillible, mais c'est solide pour la plupart des environnements de production.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!