Analysieren Sie den Sentinel-Modus in Redis und sprechen Sie über den Konstruktions- und Ausführungsprozess

Dieser Artikel vermittelt Ihnen ein detailliertes Verständnis des Sentinel-Modus in Redis und stellt die Schritte zum Erstellen des Sentinel-Modus, den Ausführungsprozess und die Sentinel-Wahl vor. Ich hoffe, dass er für alle hilfreich ist!

Grundlegende Einführung

Sentinel ist eine Hochverfügbarkeitslösung (Hochverfügbarkeit) für Redis:

• Es besteht aus einer oder mehreren Sentinel-Instanzen. Ein Sentinel-Cluster kann einen oder mehrere Master-Server und mehrere Slave-Server überwachen. [Verwandte Empfehlungen: Redis-Video-Tutorial]

• Wenn der Hauptserver offline geht, kann Sentinel einen Slave-Server unter dem Hauptserver aktualisieren, um weiterhin Dienste für den Hauptserver bereitzustellen und so die hohe Verfügbarkeit von Redis sicherzustellen.

• Abbildung: Schritte zum Erstellen des Sentinel-Modus

cp sentinel.conf sentinel‐26379.conf
cp sentinel.conf sentinel‐26380.conf
cp sentinel.conf sentinel‐26381.conf

rrree

3、 Start die Sentinel-Instanz

#Redis-Master und Redis-Slaver starten

#哨兵sentinel实例运行的端口默认26379
port 26379

#将`daemonize`由`no`改为`yes`
daemonize yes

#哨兵sentinel监控的redis主节点的 ip port
#master-name可以自己命名的主节点名字只能由字母A-z、数字0-9、这三个字符".-_"组成。#quorum当这些quorum个数sentinel哨兵认为master主节点失联那么这时客观上认为主节点失联了
#sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor master 127.0.0.1 6379 2

#当在Redis实例中开启了requirepass foobared授权密码这样所有连接Redis实例的客户端都要提供密码
#设置哨兵sentinel连接主从的密码注意必须为主从设置一样的验证密码
#sentinel auth-pass <master-name> <password>

sentinel auth-pass master MySUPER--secret-0123passw0rd

#指定多少毫秒之后主节点没有应答哨兵sentinel此时哨兵主观上认为主节点下线默认30秒，改成3秒
#sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds master 3000

#这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
#sentinel parallel-syncs <master-name> <numslaves>

sentinel parallel-syncs master 1

#故障转移的超时时间failover-timeout可以用在以下这些方面：
#1.同一个sentinel对同一个master两次failover之间的间隔时间。
#2.当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了#默认三分钟
#sentinel failover-timeout <master-name> <milliseconds>
sentinelf ailover-timeout master1 80000

#Redis-Sentinel starten

docker run -it --name redis-sentinel2639  -v /Users/yujiale/docker/redis/conf/sentinel6379.conf:/etc/redis/sentinel.conf -v /Users/yujiale/docker/redis/data26379:/data --network localNetwork --ip 172.172.0.16 -d redis:6.2.6 redis-sentinel /etc/redis/sentinel.conf

4. Überprüfen Sie den Startstatus

Ausführungsprozess

1. Starten und initialisieren Sie Sentinel

Sentinel ist ein spezieller Redis-Server, der nicht beibehalten wird.

Nachdem die Sentinel-Instanz gestartet wurde, stellt jeder Sentinel zwei Netzwerkverbindungen zum Hauptserver her der Hauptserver Der Hauptserver sendet den Befehl und empfängt die Antwort

Abonnementverbindung: Wird zum Abonnieren des --sentinel-:hello-Kanals

2 verwendet

Sentinel ist standardmäßig alle 10 Sekunden eingestellt. Senden Sie einmal den Info-Befehl an den überwachten Master-Server, um Informationen über den Master-Server und seine untergeordneten Slave-Server zu erhalten.

3. Erhalten Sie Slave-Salve-Informationen
Wenn Sentinel feststellt, dass ein neuer Slave-Server auf dem Master-Server erscheint, stellt Sentinel auch eine Befehlsverbindung und eine Abonnementverbindung zum Slave-Server her.

Nachdem die Befehlsverbindung hergestellt wurde, sendet Sentinel weiterhin standardmäßig alle 10 Sekunden den Info-Befehl an den Slave-Server und zeichnet die Informationen des Slave-Servers auf.

4. Senden Sie Nachrichten im Abonnement an den Master-Server und die Slave-Server.

Standardmäßig sendet Sentinel alle 2 Sekunden Nachrichten an alle überwachten Master- und Slave-Server. : Senden Sie eine Nachricht auf dem Hallo-Kanal. Die Nachricht enthält die eigenen Informationen von Sentinel und die Informationen des Hauptservers. 5. Kanalinformationen vom Master-Server und Slave-Server empfangen

Wenn Sentinel eine Abonnementverbindung mit dem Master-Server oder Slave-Server herstellt, sendet Sentinel den folgenden Befehl über die Abonnementverbindung an den Server

在redis-master目录下  ./redis-server redis.conf
在redis-slaver1目录下 ./redis-server redis.conf
在redis-slaver2目录下 ./redis-server redis.conf

, weil Sentinel das Hinzufügen eines neuen Sentinel erkennen kann, indem er sich beim Master-Server oder Slave-Server anmeldet. Sobald der neue Sentinel beitritt, können die sich gegenseitig bewussten Sentinels über Befehlsverbindungen kommunizieren.

6. Erkennen Sie den subjektiven Offline-Status

Sentinel sendet einmal pro Sekunde einen PING-Befehl an alle Instanzen (Master-Server, Slave-Server und andere Sentinel), die Befehlsverbindungen mit ihm hergestellt haben. Millisekunden Millisekunden Wenn innerhalb von Millisekunden eine ungültige Antwort zurückgegeben wird (außer bei +PONG, -LOADING und -MASTERDOWN) und die Instanz nicht antwortet (Timeout), betrachtet Sentinel die Instanz als subjektiv offline (SDown).

7. Überprüfen Sie objektiv den Offline-Status

Wenn ein Sentinel feststellt, dass ein Hauptserver subjektiv offline ist

Sentinel sendet Abfragebefehle an alle anderen Sentinels, die diesen Hauptserver gleichzeitig überwachen

Der Host

在redis-sentinel1目录下 ./redis-sentinel sentinel.conf
在redis-sentinel2目录下 ./redis-sentinel sentinel.conf
在redis-sentinel3目录下 ./redis-sentinel sentinel.conf

Sentinel彼此之间只创建命令连接，而不创建订阅连接Andere Sentinel-Antworten

<down_state> <leader_runid> <leader_epoch>

判断它们是否也认为主服务器下线。如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服务器为主观下线，则该主服务器就会被判定为客观下线(ODown)。

8、选举Leader Sentinel

当一个主服务器被判定为客观下线后，监视这个主服务器的所有Sentinel会通过选举算法（raft），选出一个Leader Sentinel去执行failover（故障转移）操作。

哨兵选举

Raft

Raft协议是用来解决分布式系统一致性问题的协议。

Raft协议描述的节点共有三种状态：Leader, Follower, Candidate。

term：Raft协议将时间切分为一个个的Term（任期），可以认为是一种“逻辑时间”。

选举流程

Raft采用心跳机制触发Leader选举

• 系统启动后，全部节点初始化为Follower，term为0。

• 节点如果收到了RequestVote或者AppendEntries，就会保持自己的Follower身份

• 节点如果一段时间内没收到AppendEntries消息，在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。

  • 一旦转化为Candidate，该节点立即开始下面几件事情：

    • 增加自己的term。
    • 启动一个新的定时器。
    • 给自己投一票。
    • 向所有其他节点发送RequestVote，并等待其他节点的回复。

• 如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时向所有其他节点发送AppendEntries，告知自己成为了Leader。

• 每个节点在一个term内只能投一票，采取先到先得的策略，Candidate前面说到已经投给了自己，Follower会投给第一个收到RequestVote的节点。

• Raft协议的定时器采取随机超时时间，这是选举Leader的关键。

• 在同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票。

Sentinel的leader选举流程

• 1、某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内自己就不会成为Leader。

• 2、如果该Sentinel还没投过票，那么它就成为Candidate。

• 3、Sentinel需要完成几件事情：

  • 更新故障转移状态为start
  • 当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term。
  • 向其他节点发送is-master-down-by-addr命令请求投票。命令会带上自己的epoch。
  • 给自己投一票（leader、leader_epoch）

• 4、当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；（通过判断epoch）

• 5、Candidate会不断的统计自己的票数，直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum，这时它就成为了Leader。

• 6、其他Sentinel等待Leader从slave选出master后，检测到新的master正常工作后，就会去掉客观下线的标识。

故障转移

当选举出Leader Sentinel后，Leader Sentinel会对下线的主服务器执行故障转移操作

• 1.它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master；

• 2.当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。

• 3.Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行replicaof的配置，sentinel.conf的监控目标会随之调换。

主服务器的选择

• 1.过滤掉主观下线的节点
• 2.选择slave-priority最高的节点，如果由则返回没有就继续选择
• 3.选择出复制偏移量最大的系节点，因为复制偏移量越大则数据复制的越完整，如果由就返回了，没有就继续
• 4.选择run_id最小的节点，因为run_id越小说明重启次数越少

更多编程相关知识，请访问：编程入门！！

Das obige ist der detaillierte Inhalt vonAnalysieren Sie den Sentinel-Modus in Redis und sprechen Sie über den Konstruktions- und Ausführungsprozess. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!