Der Inhalt dieses Artikels besteht darin, den Sentinel-Mechanismus von Redis vorzustellen, damit jeder das Prinzip des Sentinel-Mechanismus und seine Implementierung verstehen kann. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird Ihnen hilfreich sein.
Übersicht
Die Redis-Replikation hat einen Nachteil, wenn der Host-Master ausfällt, müssen wir manuell arbeiten Lösen Sie den Schalter, indem Sie beispielsweise den Slave von niemandem verwenden. Tatsächlich wurde die Master-Slave-Replikation nicht auf Backup-Maschinen implementiert und nutzt die Redundanz des Systems im Cluster. Wenn eine Maschine im System beschädigt ist, kann sie schnell von anderen Backup-Maschinen übernommen werden .
Probleme mit der Master-Slave-Replikation
Sobald der Masterknoten ausfällt und der Schreibdienst nicht mehr funktioniert Um verwendet zu werden, müssen Sie manuell wechseln, den Masterknoten erneut auswählen und die Master-Slave-Beziehung manuell festlegen.
Wie kann man das Problem lösen? Wenn wir über ein Überwachungsprogramm verfügen, das den Status jeder Maschine überwachen und rechtzeitig Anpassungen vornehmen kann, um manuelle Vorgänge in automatische Vorgänge umzuwandeln. Die Entstehung von Sentinel soll dieses Problem lösen.
Prinzip und Implementierung des Sentinel-Mechanismus
Redis Sentinel
Redis Sentinel ist eine verteilte Architektur, die mehrere Sentinel-Knoten und Redis-Datenknoten enthält. Wenn festgestellt wird, dass der Knoten nicht erreichbar ist, wird er als offline markiert. Wenn der identifizierte Master-Knoten der Master-Knoten ist, „verhandelt“ er auch mit anderen Sentinel-Knoten. Wenn die meisten Sentinel-Knoten glauben, dass der Master-Knoten nicht erreichbar ist, wählen sie einen Sentinel-Knoten aus, um das automatische Failover abzuschließen und ihn gleichzeitig zu benachrichtigen Diese Änderung erfolgt auf der Redis-Anwendungsseite in Echtzeit. Der gesamte Prozess läuft vollständig automatisch ab und erfordert keinen manuellen Eingriff, sodass diese Lösung das Hochverfügbarkeitsproblem von Redis effektiv löst.
Wie in der Abbildung gezeigt:
Grundlegender Failover-Prozess
1) Der Master-Knoten fällt aus. Zu diesem Zeitpunkt verlieren die beiden Slave-Knoten die Verbindung zum Master-Knoten und die Master-Slave-Replikation schlägt fehl.
2) Jeder Sentinel-Knoten stellt durch regelmäßige Überwachung fest, dass der Masterknoten ausgefallen ist
3) Mehrere Sentinel Knoten einigen sich auf den Ausfall des Primärknotens und wählen einen der Knoten als Leiter, der für das Failover verantwortlich ist.
4) Der Sentinel-Leader-Knoten hat ein Failover durchgeführt. Der gesamte Prozess ist im Grunde derselbe wie unsere manuelle Anpassung, wird jedoch automatisch abgeschlossen.
5) Nach dem Failover wählte die gesamte Redis Sentinel-Struktur erneut einen neuen Masterknoten.
Instanz
Verwenden Sie Docker, um den folgenden Redis-Container zu erstellen
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
Konfiguration
Sentinels Kernkonfiguration
sentinel monitor mymaster 127.0.0.1 7000 2
Der Name, die IP und der Port des überwachten Masterknotens. Die letzten 2 geben an, wie viele Sentinels gefunden werden. Wenn die Konfiguration beispielsweise 2 ist, bedeutet dies, dass mindestens zwei Sentinel-Knoten davon ausgehen, dass der Masterknoten nicht erreichbar ist, sodass die Feststellung der Nichterreichbarkeit objektiv ist. Je kleiner die Einstellung, desto lockerer sind die Voraussetzungen für das Erreichen des Offline-Levels und umgekehrt. Im Allgemeinen wird empfohlen, den Wert auf die Hälfte des Sentinel-Knotens plus 1 festzulegen.
sentinel down-after-millseconds mymaster 30000
Dies ist das Timeout (Einheit: Millisekunden). Wenn Sie beispielsweise eine Maschine anpingen und diese nach langer Zeit immer noch nicht anpingen können, wird dies als Problem angesehen.
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个节点,奇数个节点可以在满足该条件的基础上节省一个节点。
【相关文章】
以上就是本篇文章的全部内容,希望能对大家的学习有所帮助。更多精彩内容大家可以关注php中文网相关教程栏目!!!
Das obige ist der detaillierte Inhalt vonEinführung in die Prinzipien des Redis-Sentinel-Mechanismus (Bild und Text). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!