Rufen Sie die Slave-Serverinformationen entsprechend dem Master-Dienst ab. Es werden auch Befehlsverbindungen und Abonnementverbindungen zwischen Sentinel und Slave erstellt.
当Sentinel和Slave之间创建网络连接之后，Sentinel成为了Slave的客户端，Sentinel也会每隔10秒钟通过INFO指令请求Slave获取服务器信息。 到这一步Sentinel获取到了Master和Slave的相关服务器数据。这其中比较重要的信息如下：
此时实例结构信息如下所示：
2.7 创建Sentinel之间的网络连接
此时是不是还有疑问，Sentinel之间是怎么互相发现对方并且相互通信的，这个就和上面Sentinel与自己监视的主从之间订阅_sentinel_:hello频道有关了。 Sentinel会与自己监视的所有Master和Slave之间订阅_sentinel_:hello频道，并且Sentinel每隔2秒钟向_sentinel_:hello频道发送一条消息，消息内容如下：
PUBLISH sentinel:hello ",,,,,,,"
其中s代码Sentinel，m代表Master；ip表示IP地址，port表示端口、runid表示运行id、epoch表示配置纪元。
多个Sentinel在配置文件中会配置相同的主服务器ip和端口信息，因此多个Sentinel均会订阅_sentinel_:hello频道，通过频道接收到的信息就可获取到其他Sentinel的ip和port，其中有如下两点需要注意：
Sentinel之间不会创建订阅连接，它们只会创建命令连接：
此时实例结构信息如下所示：
3、Sentinel工作
Sentinel最主要的工作就是监视Redis服务器，当Master实例超出预设的时限后切换新的Master实例。这其中有很多细节工作，大致分为检测Master是否主观下线、检测Master是否客观下线、选举领头Sentinel、故障转移四个步骤。
3.1 检测Master是否主观下线
Sentinel每隔1秒钟，向sentinelRedisInstance实例中的所有Master、Slave、Sentinel发送PING命令，通过其他服务器的回复来判断其是否仍然在线。
sentinel down-after-milliseconds redis-master 30000
Nach dem Login kopieren
在Sentinel的配置文件中，当Sentinel PING的实例在连续down-after-milliseconds配置的时间内返回无效命令，则当前Sentinel认为其主观下线。Sentinel的配置文件中配置的down-after-milliseconds将会对其sentinelRedisInstance实例中的所有Master、Slave、Sentinel都适应。
无效指令指的是+PONG、-LOADING、-MASTERDOWN之外的其他指令，包括无响应
如果当前Sentinel检测到Master处于主观下线状态，那么它将会修改其sentinelRedisInstance的flags为SRI_S_DOWN
3.2 检测Master是否客观下线
当前Sentinel认为其下线只能处于主观下线状态，要想判断当前Master是否客观下线，还需要询问其他Sentinel，并且所有认为Master主观下线或者客观下线的总和需要达到quorum配置的值，当前Sentinel才会将Master标志为客观下线。
当前Sentinel向sentinelRedisInstance实例中的其他Sentinel发送如下命令：
SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>
Nach dem Login kopieren
Nach dem Login kopieren
current_epoch和runid均用于Sentinel的选举，Master下线之后，需要选举一个领头Sentinel来选举一个新的Master，current_epoch和runid在其中发挥着重要作用，这个后续讲解。
接收到命令的Sentinel，会根据命令中的参数检查主服务器是否下线，检查完成后会返回如下三个参数：
down_state：检查结果1代表已下线、0代表未下线
leader_runid：返回*代表判断是否下线，返回runid代表选举领头Sentinel
leader_epoch：当leader_runid返回runid时，配置纪元会有值，否则一直返回0
3.3 选举领头Sentinel
down_state返回1，证明接收is-master-down-by-addr命令的Sentinel认为该Master也主观下线了，如果down_state返回1的数量（包括本身）大于等于quorum（配置文件中配置的值），那么Master正式被当前Sentinel标记为客观下线。 此时，Sentinel会再次发送如下指令：
SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>
Nach dem Login kopieren
Nach dem Login kopieren
此时的runid将不再是0，而是Sentinel自己的运行id（runid）的值，表示当前Sentinel希望接收到is-master-down-by-addr命令的其他Sentinel将其设置为领头Sentinel。这个设置是先到先得的，Sentinel先接收到谁的设置请求，就将谁设置为领头Sentinel。 发送命令的Sentinel会根据其他Sentinel回复的结果来判断自己是否被该Sentinel设置为领头Sentinel，如果Sentinel被其他Sentinel设置为领头Sentinel的数量超过半数Sentinel（这个数量在sentinelRedisInstance的sentinel字典中可以获取），那么Sentinel会认为自己已经成为领头Sentinel，并开始后续故障转移工作（由于需要半数，且每个Sentinel只会设置一个领头Sentinel，那么只会出现一个领头Sentinel，如果没有一个达到领头Sentinel的要求，Sentinel将会重新选举直到领头Sentinel产生为止）。
3.4 故障转移
故障转移将会交给领头sentinel全权负责，领头sentinel需要做如下事情：
这其中最难的一步是如果选择最佳的新Master，领头Sentinel会做如下清洗和排序工作：
判断slave是否有下线的，如果有从slave列表中移除
删除5秒内未响应sentinel的INFO命令的slave
删除与下线主服务器断线时间超过down_after_milliseconds * 10 的所有从服务器
根据slave优先级slave_priority，选择优先级最高的slave作为新master
如果优先级相同，根据slave复制偏移量slave_repl_offset，选择偏移量最大的slave作为新master
如果偏移量相同，根据slave服务器运行id run id排序，选择run id最小的slave作为新master
新的Master产生后，领头sentinel会向已下线主服务器的其他从服务器（不包括新Master）发送SLAVEOF ip port命令，使其成为新master的slave。
到这里Sentinel的的工作流程就算是结束了，如果新master下线，则循环流程即可！
三、集群
1、简介
Redis集群是Redis提供的分布式数据库方案，集群通过分片（sharding）进行数据共享，Redis集群主要实现了以下目标：
在1000个节点的时候仍能表现得很好并且可扩展性是线性的。
没有合并操作（多个节点不存在相同的键），这样在 Redis 的数据模型中最典型的大数据值中也能有很好的表现。
Schreibsicherheit: Das System versucht, alle Schreibvorgänge zu speichern, die von Clients durchgeführt werden, die mit den meisten Knoten verbunden sind. Allerdings kann Redis nicht garantieren, dass Daten überhaupt nicht verloren gehen. Die asynchrone und synchrone Master-Slave-Replikation führt ohnehin zu Datenverlust.
Verfügbarkeit: Wenn der Masterknoten nicht verfügbar ist, kann der Slaveknoten den Masterknoten ersetzen.
Wenn Sie keine Erfahrung mit dem Erlernen von Redis-Clustern haben, wird empfohlen, diese drei Artikel (chinesische Serie) zu lesen: Redis-Cluster-Tutorial
REDIS-Cluster-Tutorial – Informationen zu Redis auf Chinesisch Station – Redis China User Group (CRUG)
Redis Cluster Specification
REDIS Cluster-Spec – Redis Chinese Information Station – Redis China User Group (CRUG)
Redis3 Master 3 Slave Pseudo-Cluster-Bereitstellung
CentOS 7 Es sind nur fünf einfache Schritte erforderlich, um den Redis-Cluster (Pseudocluster mit 3 Mastern und 3 Slaves) auf einer einzelnen Maschine zu installieren_Li Zipins Blog – CSDN-Blog
Der folgende Inhalt basiert auf der Struktur mit drei Mastern und drei Slaves im Abbildung unten:
Ressourcenliste:
| Node | IP | Slotbereich |
|---|
| Master[0] | 192.168.211 :6319 | Slots 0 - 5460 |
| Master[1] | 192.168.211.107:6329 | Slots 5461 - 10922 |
| Master[2] | 192.168.211.107:6339 | Slots 10923 - 16383 |
| Sklave[0] | 192.168.211.107:6369 |
|
| Sklave[1] | 192.168.211.107:6349 |
|
| Sklave[2] | 192.168.211.107: 6359 |
|
Führen Sie Sie durch die Master-Slave-Replikation, Sentinel und Clustering in Redis
2、集群内部
Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念。Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，这种结构很容易添加或者删除节点。集群的每个节点负责一部分hash槽，比如上面资源清单的集群有3个节点，其槽分配如下所示：
节点 Master[0] 包含 0 到 5460 号哈希槽
节点 Master[1] 包含5461 到 10922 号哈希槽
节点 Master[2] 包含10923到 16383 号哈希槽
深入学习Redis集群之前，需要了解集群中Redis实例的内部结构。当某个Redis服务节点通过cluster_enabled配置为yes开启集群模式之后，Redis服务节点不仅会继续使用单机模式下的服务器组件，还会增加custerState、clusterNode、custerLink等结构用于存储集群模式下的特殊数据。
如下三个数据承载对象一定要认真看，尤其是结构中的注释，看完之后集群大体上怎么工作的，心里就有数了，嘿嘿嘿；
2.1 clsuterNode
clsuterNode用于存储节点信息，比如节点的名字、IP地址、端口信息和配置纪元等等，以下代码列出部分非常重要的属性：
typedef struct clsuterNode {
// 创建时间
mstime_t ctime;
// 节点名字，由40位随机16进制的字符组成（与sentinel中讲的服务器运行id相同）
char name[REDIS_CLUSTER_NAMELEN];
// 节点标识，可以标识节点的角色和状态
// 角色 -> 主节点或从节点 例如：REDIS_NODE_MASTER(主节点) REDIS_NODE_SLAVE(从节点)
// 状态 -> 在线或下线 例如：REDIS_NODE_PFAIL(疑似下线) REDIS_NODE_FAIL(下线)
int flags;
// 节点配置纪元，用于故障转移，与sentinel中用法类似
// clusterState中的代表集群的配置纪元
unit64_t configEpoch;
// 节点IP地址
char ip[REDIS_IP_STR_LEN];
// 节点端口
int port;
// 连接节点的信息
clusterLink *link;
// 一个2048字节的二进制位数组
// 位数组索引值可能为0或1
// 数组索引i位置值为0，代表节点不负责处理槽i
// 数组索引i位置值为1，代表节点负责处理槽i
unsigned char slots[16384/8];
// 记录当前节点处理槽的数量总和
int numslots;
// 如果当前节点是从节点
// 指向当前从节点的主节点
struct clusterNode *slaveof;
// 如果当前节点是主节点
// 正在复制当前主节点的从节点数量
int numslaves;
// 数组——记录正在复制当前主节点的所有从节点
struct clusterNode **slaves;
} clsuterNode;Nach dem Login kopieren
上述代码中可能不太好理解的是slots[16384/8]，其实可以简单的理解为一个16384大小的数组，数组索引下标处如果为1表示当前槽属于当前clusterNode处理，如果为0表示不属于当前clusterNode处理。clusterNode能够通过slots来识别，当前节点处理负责处理哪些槽。 初始clsuterNode或者未分配槽的集群中的clsuterNode的slots如下所示：
假设集群如上面我给出的资源清单，此时代表Master[0]的clusterNode的slots如下所示：
2.2 clusterLink
clusterLink是clsuterNode中的一个属性，用于存储连接节点所需的相关信息，比如套接字描述符、输入输出缓冲区等待，以下代码列出部分非常重要的属性：
typedef struct clusterState {
// 连接创建时间
mstime_t ctime;
// TCP 套接字描述符
int fd;
// 输出缓冲区，需要发送给其他节点的消息缓存在这里
sds sndbuf;
// 输入缓冲区，接收打其他节点的消息缓存在这里
sds rcvbuf;
// 与当前clsuterNode节点代表的节点建立连接的其他节点保存在这里
struct clusterNode *node;
} clusterState;Nach dem Login kopieren
2.3 custerState
每个节点都会有一个custerState结构，这个结构中存储了当前集群的全部数据，比如集群状态、集群中的所有节点信息（主节点、从节点）等等，以下代码列出部分非常重要的属性：
typedef struct clusterState {
// 当前节点指针，指向一个clusterNode
clusterNode *myself;
// 集群当前配置纪元，用于故障转移，与sentinel中用法类似
unit64_t currentEpoch;
// 集群状态 在线/下线
int state;
// 集群中处理着槽的节点数量总和
int size;
// 集群节点字典，所有clusterNode包括自己
dict *node;
// 集群中所有槽的指派信息
clsuterNode *slots[16384];
// 用于槽的重新分配——记录当前节点正在从其他节点导入的槽
clusterNode *importing_slots_from[16384];
// 用于槽的重新分配——记录当前节点正在迁移至其他节点的槽
clusterNode *migrating_slots_to[16384];
// ...
} clusterState;Nach dem Login kopieren
在custerState有三个结构需要认真了解的，第一个是slots数组，clusterState中的slots数组与clsuterNode中的slots数组是不一样的，在clusterNode中slots数组记录的是当前clusterNode所负责的槽，而clusterState中的slots数组记录的是整个集群的每个槽由哪个clsuterNode负责，因此集群正常工作的时候clusterState的slots数组每个索引指向负责该槽的clusterNode，集群槽未分配之前指向null。
如图展示资源清单中的集群clusterState中的slots数组与clsuterNode中的slots数组：
Redis集群中使用两个slots数组的原因是出于性能的考虑：
当我们需要获取整个集群中clusterNode分别负责什么槽时，只需要查询clusterState中的slots数组即可。如果没有clusterState的slots数组，则需要遍历所有的clusterNode结构，这样显然要慢一些
此外clusterNode中的slots数组也有存在的必要，因为集群中任意一个节点之间需要知道彼此负责的槽，此时节点之间只需要互相传输clusterNode中的slots数组结构就行。
第二个需要认真了解的结构是node字典，该结构虽然简单，但是node字典中存储了所有的clusterNode，这也是Redis集群中的单个节点获取其他主节点、从节点信息的主要位置，因此我们也需要注意一下。 第三个需要认真了解的结构是importing_slots_from[16384]数组和migrating_slots_to[16384]，这两个数组在集群重新分片时需要使用，需要重点了解，后面再说吧，这里说的话顺序不太对。
3. Clusterarbeit
3.1 Wie verteile ich Slots?
Der Redis-Cluster verfügt über insgesamt 16384 Slots. Wie in der Ressourcenliste oben gezeigt, befinden wir uns in einem Cluster mit drei Mastern und drei Slaves. Das habe ich jedoch nicht gesehen Ich habe es während des Bereitstellungsprozesses der drei Master und drei Slaves oben angegeben. Dies liegt daran, dass der Redis-Cluster die Slots intern für uns aufgeteilt hat , wie sollen wir sie organisieren? Wir können den folgenden Befehl an den Knoten senden, um dem aktuellen Knoten einen oder mehrere Slots zuzuweisen:
CLUSTER ADDSLOTS
Wenn wir beispielsweise Master[0] die Slots 0 und 1 zuweisen möchten, müssen wir nur Ich muss an Master [0] denken. Der Knoten kann den folgenden Befehl senden:
CLUSTER ADDSLOTS 0 1
Wenn dem Knoten ein Steckplatz zugewiesen wird, wird das Slot-Array von ClusterNode aktualisiert und der Knoten wird aktualisiert Die Slots, für deren Verarbeitung das Slots-Array verantwortlich ist, werden an andere Knoten im Cluster gesendet. Nach dem Empfang der Nachricht aktualisieren andere Knoten das Slots-Array des entsprechenden ClusterNode und das Solts-Array des ClusterState.
3.2 Wie wird ADDSLOTS im Redis-Cluster implementiert?
Das ist eigentlich relativ einfach. Wenn wir den Befehl CLUSTER ADDSLOTS an einen Knoten im Redis-Cluster senden, bestätigt der aktuelle Knoten zunächst, ob die dem aktuellen Knoten zugewiesenen Slots nicht anderen Knoten über das Slot-Array in ClusterState zugewiesen sind. Wenn es zugewiesen wurde, wird direkt eine Ausnahme ausgelöst und der Fehler wird an den zugewiesenen Client zurückgegeben. Wenn nicht alle dem aktuellen Knoten zugewiesenen Slots anderen Knoten zugewiesen sind, weist der aktuelle Knoten diese Slots sich selbst zu. Es gibt drei Hauptschritte bei der Zuweisung:
Aktualisieren Sie das Slots-Array von ClusterState, verweisen Sie die angegebenen Slot-Slots[i] auf den aktuellen ClusterNode
Aktualisieren Sie das Slots-Array von ClusterNode, aktualisieren Sie den Wert an den angegebenen Slots[ i] bis 1
Senden Sie Nachrichten an andere Knoten im Cluster und senden Sie das Slots-Array von ClusterNode an andere Knoten. Nach dem Empfang der Nachricht aktualisieren andere Knoten auch das entsprechende Slots-Array von ClusterState und das Slots-Array von ClusterNode
3.3 Es gibt so viele Knoten im Cluster. Woher weiß der Client, welchen Knoten er anfordern muss?
Bevor Sie dieses Problem verstehen, müssen Sie zunächst einen Punkt wissen: Wie berechnet der Redis-Cluster, zu welchem Steckplatz der aktuelle Schlüssel gehört? Laut der offiziellen Website verwendet Redis eigentlich keinen konsistenten Hash-Algorithmus, sondern jeder angeforderte Schlüssel wird von CRC16 überprüft und dann Modulo 16384 verwendet, um zu bestimmen, in welchem Slot er platziert werden soll.
HASH_SLOT = CRC16(key) mod 16384
Wenn sich der Client zu diesem Zeitpunkt verbindet, um eine Anfrage an einen Knoten zu senden, berechnet der Knoten, der gerade den Befehl empfängt, zunächst den Steckplatz i, zu dem der aktuelle Schlüssel gehört Durch einen Algorithmus bestimmt der aktuelle Knoten, ob der Slot i des ClusterState für sich selbst verantwortlich ist. Wenn er dafür verantwortlich ist, antwortet der aktuelle Knoten auf die Anfrage des Clients Für den aktuellen Knoten werden die folgenden Schritte ausgeführt: - Der Knoten gibt einen MOVED-Umleitungsfehler an den Client zurück. Beim MOVED-Umleitungsfehler werden die berechnete IP und der Port des ClusterNode zurückgegeben, der den Schlüssel korrekt verarbeitet an den Client
- Wenn der Client den vom Knoten zurückgegebenen MOVED-Umleitungsfehler empfängt, wird der Befehl basierend auf der IP und dem Port an den richtigen Knoten weitergeleitet. Der gesamte Prozess ist für den Programmierer transparent und wird gemeinsam vom Knoten abgeschlossen Server und Client des Redis-Clusters.
3.4 Was passiert, wenn ich den dem Knoten A zugewiesenen Steckplatz dem Knoten B neu zuweisen möchte? Diese Frage deckt tatsächlich viele Probleme ab, z. B. das Entfernen bestimmter Knoten im Redis-Cluster, das Hinzufügen von Knoten usw. Sie kann als Verschieben des Hash-Slots von einem Knoten auf einen anderen Knoten zusammengefasst werden. Und das Coolste am Redis-Cluster ist, dass er die Online-Zuweisung (ununterbrochen) unterstützt, was offiziell als Cluster-Online-Rekonfiguration (Live-Rekonfiguration) bezeichnet wird. Schauen wir uns die CLUSTER-Anweisungen an, bevor wir sie implementieren. Sobald Sie die Anweisungen verstanden haben, können Sie sie bedienen: - CLUSTER ADDSLOTS Slot1 [Slot2] … [SlotN]
- CLUSTER DELSLOTS Slot1 [. Slot2] … [SlotN]
- CLUSTER SETSLOT Slot NODE Knoten
- CLUSTER SETSLOT Slot MIGRATING Knoten
- CLUSTER SETSLOT Slot IMPORTING Knoten
CLUSTER 用于槽分配的指令主要有如上这些，ADDSLOTS 和DELSLOTS主要用于槽的快速指派和快速删除，通常我们在集群刚刚建立的时候进行快速分配的时候才使用。CLUSTER SETSLOT slot NODE node也用于直接给指定的节点指派槽。如果集群已经建立我们通常使用最后两个来重分配，其代表的含义如下所示：
当一个槽被设置为 MIGRATING，原来持有该哈希槽的节点仍会接受所有跟这个哈希槽有关的请求，但只有当查询的键还存在原节点时，原节点会处理该请求，否则这个查询会通过一个 -ASK 重定向（-ASK redirection）转发到迁移的目标节点。
当一个槽被设置为 IMPORTING，只有在接受到 ASKING 命令之后节点才会接受所有查询这个哈希槽的请求。如果客户端一直没有发送 ASKING 命令，那么查询都会通过 -MOVED 重定向错误转发到真正处理这个哈希槽的节点那里。
上面这两句话是不是感觉不太看的懂，这是官方的描述，不太懂的话我来给你通俗的描述，整个流程大致如下步骤：
redis-trib(集群管理软件redis-trib会负责Redis集群的槽分配工作)，向目标节点（槽导入节点）发送CLUSTER SETSLOT slot IMPORTING node命令，目标节点会做好从源节点（槽导出节点）导入槽的准备工作。
redis-trib随即向源节点发送CLUSTER SETSLOT slot MIGRATING node命令，源节点会做好槽导出准备工作
redis-trib随即向源节点发送CLUSTER GETKEYSINSLOT slot count命令，源节点接收命令后会返回属于槽slot的键，最多返回count个键
redis-trib会根据源节点返回的键向源节点依次发送MIGRATE ip port key 0 timeout命令，如果key在源节点中，将会迁移至目标节点。
迁移完成之后，redis-trib会向集群中的某个节点发送CLUSTER SETSLOT slot NODE node命令，节点接收到命令后会更新clusterNode和clusterState结构，然后节点通过消息传播槽的指派信息，至此集群槽迁移工作完成，且集群中的其他节点也更新了新的槽分配信息。
3.5 如果客户端访问的key所属的槽正在迁移怎么办？
优秀的你总会想到这种并发情况，牛皮呀！大佬们！
这个问题官方也考虑了，还记得我们在聊clusterState结构的时候么？importing_slots_from和migrating_slots_to就是用来处理这个问题的。
typedef struct clusterState {
// ...
// 用于槽的重新分配——记录当前节点正在从其他节点导入的槽
clusterNode *importing_slots_from[16384];
// 用于槽的重新分配——记录当前节点正在迁移至其他节点的槽
clusterNode *migrating_slots_to[16384];
// ...
} clusterState;Nach dem Login kopieren
有了上述两个相互数组，就能判断当前槽是否在迁移了，而且从哪里迁移来，要迁移到哪里去？搞笑不就是这么简单……
此时，回到问题中，如果客户端请求的key刚好属于正在迁移的槽。那么接收到命令的节点首先会尝试在自己的数据库中查找键key，如果这个槽还没迁移完成，且当前key刚好也还没迁移完成，那就直接响应客户端的请求就行。如果该key已经不在了，此时节点会去查询migrating_slots_to数组对应的索引槽，如果索引处的值不为null，而是指向了某个clusterNode结构，那说明这个key已经被迁移到这个clusterNode了。这个时候节点不会继续在处理指令，而是返回ASKING命令，这个命令也会携带导入槽clusterNode对应的ip和port。客户端在接收到ASKING命令之后就需要将请求转向正确的节点了，不过这里有一点需要注意的地方**（因此我放个表情包在这里，方便读者注意）。**
Wie bereits erwähnt, gibt ein Knoten die MOVED-Anweisung zurück, wenn er feststellt, dass der aktuelle Slot nicht zu seiner eigenen Verarbeitung gehört. Wie geht er also mit dem zu migrierenden Slot um? Dafür ist dieser Redis-Cluster gedacht. Wenn der Knoten erkennt, dass der Slot migriert wird, gibt er einen ASKING-Befehl an den Client zurück. Der Client erhält den ASKING-Befehl, der die Knoten-IP und den Port des ClusterNode enthält, zu dem der Slot migriert wird. Dann sendet der Client zunächst einen ASKING-Befehl an den migrierenden ClusterNode. Der Zweck dieses Befehls muss darin bestehen, dem aktuellen Knoten mitzuteilen, dass Sie eine Ausnahme machen müssen, um diese Anfrage zu bearbeiten, da dieser Slot zu Ihnen migriert wurde und Sie dies nicht können lehne mich direkt ab ( Wenn Redis den ASKING-Befehl nicht erhält, fragt es den ClusterState des Knotens direkt ab, und der zu migrierende Slot wurde nicht auf den ClusterState aktualisiert, sodass er nur MOVED direkt zurückgeben kann, was zu einer weiteren Schleife führt viele Male...), empfangen Der Knoten mit dem ASKING-Befehl führt diese Anforderung einmal zwangsweise aus (nur einmal, und Sie müssen den ASKING-Befehl beim nächsten Mal erneut im Voraus senden).
4. Cluster-Fehler
Redis-Cluster-Fehler sind eigentlich ähnlich wie bei Sentinel, wenn der Master-Knoten ausfällt oder nicht innerhalb der angegebenen maximalen Zeit antwortet und ein neuer Master-Knoten wiedergewählt wird die Slave-Knoten. Die Voraussetzung ist natürlich, dass wir für jeden Masterknoten im Redis-Cluster im Voraus einen Slave-Knoten eingerichtet haben, sonst ist er nutzlos ... Die allgemeinen Schritte sind wie folgt:
In einem normal funktionierenden Cluster sendet jeder Knoten regelmäßig PING-Befehle an andere Knoten. Wenn der Knoten, der den Befehl empfängt, innerhalb der angegebenen Zeit keine PONG-Nachricht zurücksendet, sendet der aktuelle Knoten Der PING-Befehl an den Knoten, der den Befehl empfängt, ist auf REDIS_NODE_PFAIL gesetzt, es wird jedoch vermutet, dass er offline ist.
Der Clusterknoten benachrichtigt andere Knoten, indem er Nachrichten über die Statusinformationen jedes Knotens im Cluster sendet.
Wenn mehr als die Hälfte der Masterknoten im Cluster, die für die Verarbeitung von Slots verantwortlich sind, einen bestimmten Masterknoten wie vermutet festlegen offline , dann wird dieser Knoten als offline markiert und der Knoten setzt die Flags des Clusterknotens, der den Befehl empfängt, auf REDIS_NODE_FAIL. Dies zeigt an, dass er offline ist
Der Clusterknoten informiert andere Knoten, indem er Nachrichten sendet Cluster Die Statusinformationen jedes Knotens im Offline-Knoten. Zu diesem Zeitpunkt stellt der Slave-Knoten des Offline-Knotens fest, dass sein Master-Knoten als offline markiert wurde, sodass es an der Zeit ist, vorwärts zu gehen Der Slave-Knoten des Offline-Master-Knotens wird einen Slave-Knoten als neuesten Master-Knoten erstellen und den ausgewählten Knoten ausführen, um SLAVEOF niemanden zum neuen Master-Knoten zu zeigen
Der neue Master-Knoten widerruft die Slot-Zuweisungen des ursprünglichen Master-Knotens und ändert diese Slots Zuweisungen an sich selbst. Das heißt, die ClusterNode-Struktur und die ClusterState-Struktur zu ändern. Der neue Masterknoten sendet eine PONG-Anweisung an den Cluster. Andere Knoten wissen, dass ein neuer Masterknoten generiert wurde, und aktualisieren die ClusterNode-Struktur und die ClusterState-Struktur
der neue Masterknoten Wenn eine neue SLAVEOF-Anweisung an die verbleibenden Slaveknoten des ursprünglichen Masterknotens gesendet wird, wird dieser zu seinem eigenen Slaveknoten
Der letzte neue Masterknoten ist für die Antwortarbeit des verantwortlich Slot des ursprünglichen Master-Knotens
Ich habe hier sehr viel geschrieben Fuzzy, wenn Sie eine detaillierte Ausgrabung benötigen, müssen Sie diesen Artikel lesen:
- REDIS Cluster-Spec – Redis Chinese Information Station – Redis China User Group (CRUG ) http://redis.cn/topics/cluster- spec.html
Oder Sie können das Buch „Redis Design and Implementation“ von Huang Jianhong lesen. Dieses Buch ist sehr gut, und ich habe auch auf a verwiesen viel Inhalt.
Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Programmiervideos
! !
