Redis Advanced Learning High Availability Sentinel (Zusammenfassungsfreigabe)

Dieser Artikel vermittelt Ihnen relevantes Wissen über Hochverfügbarkeits-Sentinel in Redis, einschließlich Fragen im Zusammenhang mit Funktionsarchitektur, Bereitstellung und Konfiguration. Ich hoffe, dass er für alle hilfreich ist.

Empfohlenes Lernen: Redis-Video-Tutorial

1. Funktion und Architektur

1. Funktion

Bevor Sie Sentinel vorstellen, überprüfen Sie zunächst die Technologien im Zusammenhang mit der Hochverfügbarkeit von Redis aus einer Makroperspektive. Dazu gehören: Persistenz, Replikation, Sentinel und Cluster. Ihre Hauptfunktionen und gelösten Probleme sind:

• Persistenz: Persistenz ist die einfachste Hochverfügbarkeitsmethode (manchmal nicht einmal als Hochverfügbarkeitsmethode klassifiziert), hauptsächlich Die Funktion besteht aus Daten Backup, das heißt, die Daten werden auf der Festplatte gespeichert, um sicherzustellen, dass die Daten aufgrund des Prozessabbruchs nicht verloren gehen.
• Replikation: Die Replikation ist die Grundlage für hochverfügbares Redis. Sowohl Sentinel als auch Cluster erreichen Hochverfügbarkeit basierend auf Replikation. Die Replikation implementiert hauptsächlich die Sicherung von Daten auf mehreren Computern sowie den Lastausgleich und die einfache Fehlerwiederherstellung für Lesevorgänge. Nachteile: Die Wiederherstellung nach Fehlern kann nicht automatisiert werden; die Lastverteilung von Schreibvorgängen ist nicht durch eine einzelne Maschine begrenzt.
• Sentinel: Basierend auf der Replikation implementiert Sentinel eine automatisierte Fehlerwiederherstellung. Nachteile: Schreibvorgänge können nicht lastverteilt werden; die Speicherkapazität ist durch eine einzelne Maschine begrenzt.
• Cluster: Durch Clustering löst Redis das Problem, dass bei Schreibvorgängen kein Lastausgleich möglich ist und die Speicherkapazität durch eine einzelne Maschine begrenzt ist, wodurch eine relativ vollständige Hochverfügbarkeitslösung erreicht wird.

Jetzt reden wir über den Wachposten.

Redis Sentinel, der Redis Sentinel, wurde in Redis Version 2.8 eingeführt. Die Kernfunktion von Sentinel ist das automatische Failover des Masterknotens. Das Folgende ist die Beschreibung der Sentinel-Funktion im offiziellen Redis-Dokument:

• Überwachung: Sentinel prüft kontinuierlich, ob der Master-Knoten und die Slave-Knoten normal funktionieren.
• Automatisches Failover: Wenn der Master-Knoten nicht ordnungsgemäß funktionieren kann, startet Sentinel einen automatischen Failover-Vorgang. Dabei wird einer der Slave-Knoten des ausgefallenen Master-Knotens auf den neuen Master-Knoten aktualisiert, und die anderen Slave-Knoten können ihn kopieren neuer Masterknoten.
• Konfigurationsanbieter: Während der Initialisierung erhält der Client die Masterknotenadresse des aktuellen Redis-Dienstes, indem er eine Verbindung zum Sentinel herstellt.
• Benachrichtigung: Sentinel kann die Failover-Ergebnisse an den Client senden.

Unter anderem ermöglichen die Überwachungs- und automatischen Failover-Funktionen es Sentinel, Ausfälle des Masterknotens rechtzeitig zu erkennen und die Übertragung abzuschließen, während die Konfigurationsanbieter- und Benachrichtigungsfunktionen in der Interaktion mit dem Client berücksichtigt werden müssen.

Hier ist eine Erklärung der Verwendung des Wortes „Client“ im Artikel: Solange im vorherigen Artikel auf den Redis-Server über die API zugegriffen wird, wird er als Client bezeichnet, einschließlich redis-cli, Java-Client Jedis usw.; Um die Unterscheidung und Erklärung zu erleichtern, enthält der Client in diesem Artikel kein Redis-Cli, sondern ist komplexer als Redis-Cli: Redis-Cli verwendet die von Redis bereitgestellte zugrunde liegende Schnittstelle, während der Client diese kapselt Schnittstellen und Funktionen, um die Konfigurationsanbieter und Benachrichtigungsfunktionen von Sentinel voll auszunutzen.

2. Architektur

Das typische Sentinel-Architekturdiagramm sieht wie folgt aus:

Es besteht aus zwei Teilen, dem Sentinel-Knoten und dem Datenknoten:

• Sentinel-Knoten: Das Sentinel-System besteht aus einem oder mehreren Sentinel Knoten, Sentinel-Knoten sind spezielle Redis-Knoten, die keine Daten speichern.
• Datenknoten: Masterknoten und Slaveknoten sind beide Datenknoten.

2. Bereitstellung

In diesem Teil wird ein einfaches Sentinel-System bereitgestellt, einschließlich 1 Master-Knoten, 2 Slave-Knoten und 3 Sentinel-Knoten. Der Einfachheit halber: Alle diese Knoten werden auf einem Computer bereitgestellt (LAN-IP: 192.168.92.128), unterschieden nach Portnummern, wird die Konfiguration der Knoten so weit wie möglich vereinfacht.

1. Master-Slave-Knoten bereitstellen

Die Master-Slave-Knoten im Sentinel-System sind die gleichen wie normale Master-Slave-Knoten und erfordern keine zusätzliche Konfiguration. Im Folgenden sind die Konfigurationsdateien des Master-Knotens (Port=6379) und der beiden Slave-Knoten (Port=6380/6381) aufgeführt. Die Konfigurationen sind relativ einfach und werden nicht im Detail beschrieben.

#redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
#redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 192.168.92.128 6379
#redis-6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 192.168.92.128 6379

redis-server redis-6379.conf
redis-server redis-6380.conf
redis-server redis-6381.conf

Stellen Sie nach dem Start des Knotens eine Verbindung zum Masterknoten her, um zu überprüfen, ob der Master-Slave-Status normal ist. Nachdem die Konfiguration abgeschlossen ist, starten Sie den Master-Knoten und den Slave-Knoten nacheinander:

2 Stellen Sie den Sentinel-Knoten bereit.

Der Sentinel-Knoten ist im Wesentlichen ein spezieller Redis-Knoten.

Die Konfigurationen der drei Sentinel-Knoten sind nahezu identisch. Der Hauptunterschied besteht in der Portnummer (26379/26380/26381). Im Folgenden wird die Knotenkonfiguration und die Startmethode als Beispiel verwendet Der Teil ist so einfach wie möglich, mehr Konfiguration wird später eingeführt.

#sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 192.168.92.128 6379 2

哨兵节点的启动有两种方式，二者作用是完全相同的：其中，sentinel monitor mymaster 192.168.92.128 6379 2 配置的含义是：该哨兵节点监控192.168.92.128:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。

redis-sentinel sentinel-26379.conf
redis-server sentinel-26379.conf --sentinel

3.  总结

按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过redis-cli连接哨兵节点进行验证

哨兵系统的搭建过程，有几点需要注意：

（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。

（2）哨兵节点本质上是redis节点。

（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。

三、客户端访问哨兵系统

上一小节演示了哨兵的两大作用：监控和自动故障转移，本小节则结合客户端演示哨兵的另外两个作用：配置提供者和通知。

1.  代码示例

在介绍客户端的原理之前，先以Java客户端Jedis为例，演示一下使用方法：下面代码可以连接我们刚刚搭建的哨兵系统，并进行各种读写操作（代码中只演示如何连接哨兵，异常处理、资源关闭等未考虑）。

public static void testSentinel() throws Exception {
         String masterName = "mymaster";
         Set<String> sentinels = new HashSet<>();
         sentinels.add("192.168.92.128:26379");
         sentinels.add("192.168.92.128:26380");
         sentinels.add("192.168.92.128:26381");
         JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作
         Jedis jedis = pool.getResource();
         jedis.set("key1", "value1");
         pool.close();
}

Jedis客户端对哨兵提供了很好的支持。如上述代码所示，我们只需要向Jedis提供哨兵节点集合和masterName，构造JedisSentinelPool对象；然后便可以像使用普通redis连接池一样来使用了：通过pool.getResource()获取连接，执行具体的命令。2.  客户端原理

在整个过程中，我们的代码不需要显式的指定主节点的地址，就可以连接到主节点；代码中对故障转移没有任何体现，就可以在哨兵完成故障转移后自动的切换主节点。之所以可以做到这一点，是因为在JedisSentinelPool的构造器中，进行了相关的工作；主要包括以下两点：

（1）遍历哨兵节点，获取主节点信息：遍历哨兵节点，通过其中一个哨兵节点+masterName获得主节点的信息；该功能是通过调用哨兵节点的sentinel get-master-addr-by-name命令实现，该命令示例如下：

一旦获得主节点信息，停止遍历（因此一般来说遍历到第一个哨兵节点，循环就停止了）。

（2）增加对哨兵的监听：这样当发生故障转移时，客户端便可以收到哨兵的通知，从而完成主节点的切换。具体做法是：利用redis提供的发布订阅功能，为每一个哨兵节点开启一个单独的线程，订阅哨兵节点的+switch-master频道，当收到消息时，重新初始化连接池。

3.  总结

通过客户端原理的介绍，可以加深对哨兵功能的理解：

（1）配置提供者：客户端可以通过哨兵节点+masterName获取主节点信息，在这里哨兵起到的作用就是配置提供者。

需要注意的是，哨兵只是配置提供者，而不是代理。二者的区别在于：如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求(如set/get)会直接发向主节点；如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。

举一个例子可以很好的理解哨兵的作用是配置提供者，而不是代理。在前面部署的哨兵系统中，将哨兵节点的配置文件进行如下修改：

sentinel monitor mymaster 192.168.92.128 6379 2
改为
sentinel monitor mymaster 127.0.0.1 6379 2

（2）通知：哨兵节点在故障转移完成后，会将新的主节点信息发送给客户端，以便客户端及时切换主节点。然后，将前述客户端代码在局域网的另外一台机器上运行，会发现客户端无法连接主节点；这是因为哨兵作为配置提供者，客户端通过它查询到主节点的地址为127.0.0.1:6379，客户端会向127.0.0.1:6379建立redis连接，自然无法连接。如果哨兵是代理，这个问题就不会出现了。

四、基本原理

前面介绍了哨兵部署、使用的基本方法，本部分介绍哨兵实现的基本原理。

1. Vom Sentinel-Knoten unterstützte Befehle

Der Sentinel-Knoten ist ein Redis-Knoten, der in einem speziellen Modus ausgeführt wird, und die von ihm unterstützten Befehle unterscheiden sich von gewöhnlichen Redis-Knoten. Im Betrieb und bei der Wartung können wir das Sentinel-System über diese Befehle abfragen oder ändern. Noch wichtiger ist jedoch, dass das Sentinel-System untrennbar mit der Kommunikation zwischen den Sentinel-Knoten verbunden ist, um verschiedene Funktionen wie Fehlererkennung und Failover zu implementieren Die Kommunikation ist sehr hoch. Das meiste davon wird durch Befehle erreicht, die von Sentinel-Knoten unterstützt werden. Im Folgenden werden die wichtigsten vom Sentinel-Knoten unterstützten Befehle vorgestellt.

(1) Grundlegende Abfrage: Mit diesen Befehlen können Sie die Topologie, Knoteninformationen, Konfigurationsinformationen usw. des Sentinel-Systems abfragen.

• Info Sentinel: Erhalten Sie grundlegende Informationen zu allen überwachten Masterknoten.
• Sentinel Master: Erhalten Sie detaillierte Informationen zu allen überwachten Masterknoten.
• Sentinel Master Mymaster: Erhalten Sie detaillierte Informationen zu den überwachten Masterknoten Mymaster Informationen des überwachten Master-Knotens Mymaster und des Slave-Knotens
• sentinel sentinels mymaster: Erhalten Sie die detaillierten Informationen des überwachten Sentinel-Knotens mymaster
• sentinel get-master-addr-by-name mymaster: Erhalten Sie die Adressinformationen des überwachten Master-Knotens mymaster wurde bereits eingeführt
• sentinel is-master-down-by-addr: Sentinel-Knoten können diesen Befehl verwenden, um zu fragen, ob der Masterknoten offline ist, um zu beurteilen, ob er objektiv offline ist
• (2) Hinzufügen/Entfernen die Überwachung des Masterknotens

Sentinel Monitor Mymaster2 192.168.92.128 16379 2: Die Funktion des Sentinel Monitors in der Konfigurationsdatei ist genau die gleiche wie bei der Bereitstellung des Sentinel Nodes und wird nicht im Detail beschrieben

Sentinel Remove Mymaster2: Brechen Sie die aktuelle Sentinel-Node-Überwachung des Master-Knotens mymaster2 ab. Wenn der aktuelle Masterknoten kurz vor der Verschrottung steht, können Sie ein Failover im Voraus über den Failover-Befehl durchführen.

2. Grundprinzipien

In Bezug auf das Prinzip des Wächters liegt der Schlüssel darin, die folgenden Konzepte zu verstehen.

(1) Geplante Aufgaben: Jeder Sentinel-Knoten verwaltet 3 geplante Aufgaben. Die Funktionen der geplanten Aufgaben sind wie folgt: Erhalten Sie die neueste Master-Slave-Struktur, indem Sie den Info-Befehl an den Master-Slave-Knoten senden. Erhalten Sie die Informationen anderer Sentinel-Knoten über die Veröffentlichungs- und Abonnementfunktion Befehl an andere Knoten senden, um festzustellen, ob sie offline sind. (2) Subjektiv offline: Wenn bei der geplanten Aufgabe der Heartbeat-Erkennung andere Knoten für einen bestimmten Zeitraum nicht antworten, werden sie vom Sentinel-Knoten subjektiv offline geschaltet. Wie der Name schon sagt, bedeutet „subjektiv offline“, dass ein Sentinel-Knoten offline „subjektiv“ urteilt; das Gegenstück zu „subjektiv offline“ ist objektiv offline. (3) Ziel offline: Nachdem der Sentinel-Knoten den Master-Knoten subjektiv offline geschaltet hat, fragt er andere Sentinel-Knoten über den Befehl sentinel is-master-down-by-addr nach dem Status des Master-Knotens Der Masterknoten ist offline. Wenn die Anzahl der Sentinels einen bestimmten Wert erreicht, ist der Masterknoten objektiv offline.

Es ist wichtig zu beachten, dass der objektive Offline-Vorgang nur für den Master-Knoten gilt. Wenn der Slave-Knoten und der Sentinel-Knoten ausfallen, gibt es keine weiteren objektiven Offline- und Failover-Vorgänge, nachdem der Sentinel ihn subjektiv offline geschaltet hat.

(4) Wählen Sie den führenden Sentinel-Knoten: Wenn festgestellt wird, dass der Master-Knoten objektiv offline ist, verhandelt jeder Sentinel-Knoten über die Wahl eines führenden Sentinel-Knotens, und der führende Knoten führt darauf Failover-Operationen durch.

Alle Sentinels, die den Master-Knoten überwachen, können zum Anführer gewählt werden. Der bei der Wahl verwendete Algorithmus ist der Raft-Algorithmus , Sentinel A sendet eine Nachricht an B, um der Anführer zu werden. Wenn B den anderen Sentinels nicht zugestimmt hat, stimmt er zu, dass A der Anführer wird. Der konkrete Prozess der Wahl wird hier nicht im Detail beschrieben. Generell gilt, dass derjenige, der das Ziel zuerst offline erreicht, zum Anführer wird.

(5) Failover: Der gewählte Leader-Sentinel startet den Failover-Vorgang, der grob in drei Schritte unterteilt werden kann:

Wählen Sie einen neuen Master-Knoten vom Slave-Knoten aus: Das Auswahlprinzip besteht darin, zuerst fehlerhafte Slave-Knoten herauszufiltern; Wählen Sie dann den Slave-Knoten mit der höchsten Priorität aus (angegeben durch Slave-Priorität). Wenn die Prioritäten nicht unterschieden werden können, wählen Sie den Slave-Knoten mit dem größten Replikationsoffset aus .

Aktualisieren Sie den Master-Slave-Status: Verwenden Sie den Befehl „slaveof no one“, um den ausgewählten Slave-Knoten zum Master-Knoten zu machen, und verwenden Sie den Befehl „slaveof“, um andere Knoten zu seinen Slave-Knoten zu machen.

Legen Sie den Offline-Masterknoten (d. h. 6379) als Slave-Knoten des neuen Masterknotens fest. Wenn 6379 wieder online ist, wird er zum Slave-Knoten des neuen Masterknotens.

5. Konfigurations- und Übungsvorschläge

1. Im Folgenden werden verschiedene Konfigurationen im Zusammenhang mit Sentinel vorgestellt.

(1) Sentinel-Monitor {masterName} {masterIp} {masterPort} {quorum}

• Der Sentinel-Monitor ist die Kernkonfiguration des Sentinels. Dies wurde bereits bei der Bereitstellung des Sentinel-Knotens erläutert. Darunter: masterName gibt den Master-Knotennamen an, masterIp und masterPort geben die Master-Knotenadresse an und Quorum ist die Schwellenwertanzahl der Sentinels um zu beurteilen, ob der Masterknoten offline ist: Wenn die Anzahl der Sentinels, die feststellen, dass der Masterknoten offline ist, das Quorum erreicht, ist der Masterknoten objektiv offline. Der empfohlene Wert ist die Hälfte der Anzahl der Sentinels plus 1.

  (2) Sentinel-Ausfall nach Millisekunden {MasterName} {Zeit}

  Sentinel-Ausfall nach Millisekunden hängt mit der subjektiven Offline-Beurteilung zusammen: Der Sentinel verwendet den Ping-Befehl, um die Heartbeat-Erkennung auf anderen Knoten durchzuführen Knoten überschreiten den Ausfall – Wenn innerhalb der konfigurierten Zeit nach Millisekunden keine Antwort erfolgt, protokolliert Sentinel sie subjektiv offline. Diese Konfiguration gilt für die subjektive Offline-Bestimmung von Master-Knoten, Slave-Knoten und Sentinel-Knoten.

  Der Standardwert für den Ausfall nach Millisekunden beträgt 30.000, was 30 Sekunden entspricht. Er kann je nach Netzwerkumgebung und Anwendungsanforderungen angepasst werden: Je größer der Wert, desto lockerer ist die subjektive Beurteilung des Offline-Zustands Die Fehleinschätzung ist gering. Der Nachteil besteht darin, dass die Zeit für die Fehlererkennung und das Failover länger wird und auch die Wartezeit des Clients länger wird. Wenn die Anwendung beispielsweise hohe Verfügbarkeitsanforderungen hat, kann der Wert entsprechend reduziert werden, um die Übertragung so schnell wie möglich abzuschließen, wenn ein Fehler auftritt. Wenn die Netzwerkumgebung relativ schlecht ist, kann der Schwellenwert entsprechend erhöht werden, um häufige Fehleinschätzungen zu vermeiden.

  (3) Sentinel Parallel-Syncs {MasterName} {Anzahl}

  Sentinel Parallel-Syncs beziehen sich auf die Replikation von Slave-Knoten nach einem Failover: Sie geben die Anzahl der Slave-Knoten an, die jedes Mal Replikationsvorgänge auf dem neuen Master-Knoten initiieren . Nehmen wir beispielsweise an, dass nach Abschluss des Master-Knotenwechsels drei Slave-Knoten die Replikation auf den neuen Master-Knoten initiieren möchten, wenn Parallel-Syncs = 1 ist. dann 3 Slave-Knoten Die Knoten beginnen gemeinsam zu replizieren.

  Je größer der Wert der Parallelsynchronisierungen ist, desto schneller dauert es, bis der Slave-Knoten die Replikation abschließt, aber desto größer ist der Druck auf die Netzwerklast und die Festplattenlast des Master-Knotens. Dies sollte entsprechend der tatsächlichen Situation eingestellt werden . Wenn beispielsweise die Last auf dem Master-Knoten gering ist und der Slave-Knoten hohe Anforderungen an die Dienstverfügbarkeit stellt, können Sie den Parallel-Syncs-Wert entsprechend erhöhen. Der Standardwert für Parallelsynchronisierungen ist 1.

  (4) Sentinel-Failover-Timeout {masterName} {time}

  Sentinel-Failover-Timeout hängt mit der Beurteilung des Failover-Timeouts zusammen, dieser Parameter wird jedoch nicht zur Beurteilung des Timeouts der gesamten Failover-Phase verwendet, sondern seiner mehreren Sub -Phasen, zum Beispiel, wenn die Zeit, die der Master-Knoten benötigt, um zum Slave-Knoten heraufgestuft zu werden, das Timeout überschreitet, oder die Zeit, die der Slave-Knoten benötigt, um einen Replikationsvorgang auf den neuen Master-Knoten zu initiieren (ohne die Zeit zum Kopieren von Daten). Wenn die Zeitüberschreitung überschritten wird, führt dies zu einer Zeitüberschreitung des Failovers.

  Der Standardwert des Failover-Timeouts ist 180000, was 180 Sekunden entspricht; wenn es zu einer Zeitüberschreitung kommt, wird der Wert beim nächsten Mal doppelt so hoch wie der ursprüngliche Wert.

  (5) Zusätzlich zu den oben genannten Parametern gibt es einige andere Parameter, z. B. Parameter im Zusammenhang mit der Sicherheitsüberprüfung, die hier nicht vorgestellt werden.

  2. Praktische Vorschläge

  (1) Die Anzahl der Sentinel-Knoten sollte mehr als eins betragen. Einerseits erhöht es die Redundanz der Sentinel-Knoten und verhindert, dass die Sentinels selbst zu einem Hochverfügbarkeitsengpass werden Andererseits reduziert es Fehleinschätzungen von Offline. Darüber hinaus sollten diese verschiedenen Sentinel-Knoten auf unterschiedlichen physischen Maschinen bereitgestellt werden.

  (2) Die Anzahl der Sentinel-Knoten sollte eine ungerade Zahl sein, um den Sentinels das Treffen von „Entscheidungen“ durch Abstimmungen zu erleichtern: Entscheidungen über die Wahl des Anführers, Entscheidungen über Ziele offline usw.

  (3) Die Konfiguration jedes Sentinel-Knotens sollte konsistent sein, einschließlich Hardware, Parameter usw. Darüber hinaus sollten alle Knoten NTP oder ähnliche Dienste verwenden, um eine genaue und konsistente Zeit sicherzustellen.

  (4) Die Konfigurationsanbieter- und Benachrichtigungs-Client-Funktionen von Sentinel erfordern die Implementierung von Client-Unterstützung, wie z. B. Jedis oben erwähnt. Wenn die vom Entwickler verwendete Bibliothek keine entsprechende Unterstützung bietet, muss der Entwickler diese möglicherweise selbst implementieren.

  (5) Wenn die Knoten im Sentinel-System in Docker (oder einer anderen Software, die eine Portzuordnung durchführen kann) bereitgestellt werden, sollte besonders darauf geachtet werden, dass die Portzuordnung dazu führen kann, dass das Sentinel-System nicht ordnungsgemäß funktioniert, da die Die Arbeit von Sentinel basiert auf der Kommunikation mit anderen Knoten, und die Portzuordnung von Docker kann dazu führen, dass Sentinel keine Verbindung zu anderen Knoten herstellen kann. Beispielsweise hängt die gegenseitige Erkennung durch Sentinels von der IP und dem Port ab, die sie der Außenwelt mitteilen. Wenn ein Sentinel A in einem Docker mit Portzuordnung bereitgestellt wird, können andere Sentinels keine Verbindung zu A über den von A deklarierten Port herstellen.

  6. Zusammenfassung: Dieser Artikel stellt zunächst die Rolle von Sentinel vor: Überwachung, Failover, Konfigurationsanbieter und Benachrichtigung. Anschließend werden die Bereitstellungsmethode des Sentinel-Systems und die Methode zum Zugriff auf das Sentinel-System über den Client beschrieben Abschließend werden einige Vorschläge zur Sentinel-Praxis gegeben.

  Basierend auf der Master-Slave-Replikation führt Sentinel ein automatisches Failover des Master-Knotens ein, wodurch die hohe Verfügbarkeit von Redis weiter verbessert wird. Der Fehler von Sentinel ist jedoch auch offensichtlich: Sentinel kann kein automatisches Failover des Slave-Knotens durchführen, und der Lese- Schreibtrennung In diesem Szenario führt der Ausfall des Slave-Knotens dazu, dass der Lesedienst nicht verfügbar ist, sodass wir zusätzliche Überwachungs- und Schaltvorgänge auf dem Slave-Knoten durchführen müssen.

  Außerdem hat Sentinel das Problem, dass Schreibvorgänge nicht lastausgleichbar sind und die Speicherkapazität durch eine einzelne Maschine begrenzt ist, immer noch nicht gelöst. Die Lösung dieser Probleme erfordert die Verwendung von Clustern, die ich in einem späteren Artikel vorstellen werde. Seien Sie herzlich willkommen, aufmerksam zu sein.

  Empfohlenes Lernen: „Redis-Video-Tutorial“, „2022 neueste Fragen und Antworten zu Redis-Interviews“

Das obige ist der detaillierte Inhalt vonRedis Advanced Learning High Availability Sentinel (Zusammenfassungsfreigabe). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!