Introduction aux principes du mécanisme sentinelle Redis (image et texte)

Le contenu de cet article est de présenter le mécanisme sentinelle de Redis pour permettre à chacun de comprendre le principe du mécanisme sentinelle et comment le mettre en œuvre. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Vue d'ensemble

La réplication Redis présente un défaut Lorsque le maître hôte tombe en panne, nous avons besoin de résoudre. le commutateur manuellement, par exemple en utilisant l'esclave de personne. En effet, la réplication maître-esclave n'a pas été implémentée. La haute disponibilité se concentre sur les machines de sauvegarde et utilise la redondance du système dans le cluster. Lorsqu'une machine du système est endommagée, d'autres machines de sauvegarde peuvent rapidement la prendre en charge pour démarrer le service. .

Problèmes de réplication maître-esclave

Une fois que le nœud maître tombe en panne et que le service d'écriture ne peut pas être utilisé, vous devez changer manuellement, resélectionner le nœud maître et définir manuellement la relation maître-esclave.

Alors comment le résoudre ? Si nous disposons d'un programme de surveillance capable de surveiller l'état de chaque machine et d'effectuer des ajustements en temps opportun, transformant les opérations manuelles en opérations automatiques. L’émergence de Sentinel vise à résoudre ce problème.

Principe et mise en œuvre du mécanisme sentinelle

Redis Sentinel

Redis Sentinel est une architecture distribuée qui contient plusieurs nœuds Sentinel et nœuds de données Redis. Chaque nœud Sentinel surveille le nœud de données et les autres nœuds Sentinel. Lorsqu'il constate que le nœud est inaccessible, il le marquera hors ligne. Si le nœud maître identifié est le nœud maître, il « négociera » également avec d'autres nœuds Sentinel. Lorsque la plupart des nœuds Sentinel pensent que le nœud maître est inaccessible, ils éliront un nœud Sentinel pour effectuer le basculement automatique et en informeront en même temps le nœud maître. Côté application Redis de ce changement en temps réel. L'ensemble du processus est entièrement automatique et ne nécessite aucune intervention manuelle, cette solution résout donc efficacement le problème de haute disponibilité de Redis.

Comme le montre la figure :

Processus de basculement de base

1) Le nœud maître échoue à ce moment, les deux nœuds esclaves perdent la connexion avec le nœud maître et la réplication maître-esclave échoue.

2) Chaque nœud Sentinel découvre que le nœud maître a échoué grâce à une surveillance régulière

3) Plusieurs Sentinel Le les nœuds se mettent d'accord sur la défaillance du nœud principal et élisent l'un des nœuds comme leader responsable du basculement.

4) Le nœud leader Sentinel a effectué le basculement. L'ensemble du processus est fondamentalement le même que notre ajustement manuel, mais il est terminé automatiquement.

5) Après le basculement, l'ensemble de la structure Redis Sentinel a réélu un nouveau nœud maître.

Instance

Utilisez Docker pour créer le conteneur Redis suivant

redis-sentinel1    172.10.0.9    22530 -> 22530    sentinel
redis-sentinel2    172.10.0.10    22531 -> 6379    sentinel
redis-sentinel3    172.10.0.11    22532 -> 6379    sentinel
redis-master2    172.10.0.5    6383  -> 6379    Master
redis-slave2    172.10.0.6    6384  -> 6379    Slave
redis-slave3    172.10.0.7    6385  -> 6379    Slave

Configuration

Configuration de base de Sentinel

sentinel monitor mymaster 127.0.0.1 7000 2

Le nom, l'adresse IP et le port du nœud maître surveillé Que signifient les 2 derniers. ? Si Sentinel détecte un problème, un basculement se produira. Par exemple, si la configuration est 2, cela signifie qu'au moins deux nœuds Sentinel pensent que le nœud maître est inaccessible. Cette détermination d'inaccessibilité est alors objective. Plus le paramètre est petit, plus les conditions pour atteindre le niveau hors ligne sont souples, et vice versa. Il est généralement recommandé de le définir sur la moitié du nœud Sentinel plus 1.

sentinel down-after-millseconds mymaster 30000

C'est le délai d'attente (en millisecondes). Par exemple, lorsque vous envoyez une requête ping à une machine et que vous ne parvenez toujours pas à la tester après une longue période, cela est alors considéré comme un problème.

sentinel parallel-syncs mymaster 1

当 Sentinel 节点集合对主节点故障判定达成一致时，Sentinel 领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs 就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数，指出 Sentinel 属于并发还是串行。1代表每次只能复制一个，可以减轻 Master 的压力。

sentinel auth-pass <master-name> <password></password></master-name>

如果 Sentinel 监控的主节点配置了密码，sentinel auth-pass 配置通过添加主节点的密码，防止 Sentinel 节点对主节点无法监控。

sentinel failover-timeout mymaster 180000

表示故障转移的时间。

技巧

1）Sentinel 节点不应该部署在一台物理“机器”上。

这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器，它们虽然有不同的 IP 地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现 Sentinel 节点集合真正的高可用，请勿将 Sentinel 节点部署在同一台物理机器上。

2）部署至少三个且奇数个的 Sentinel 节点。

3个以上是通过增加 Sentinel 节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。

【相关文章】

Redis主从复制的原理介绍（图文）

以上就是本篇文章的全部内容，希望能对大家的学习有所帮助。更多精彩内容大家可以关注php中文网相关教程栏目！！！

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!