摘要：本笔记是对的归纳总结。传播的配置赢得选举之后会在己侧更新上的归属信息，然后在定时的中将这个信息传播出去。这个过程不需要共识，因为只是修改的归属，也不会修改。同样不需要大多数同意。
本笔记是对Redis Cluster Spec - Configuration handling, propagation, and failovers的归纳总结。
Epoch可以把Epoch当作是一个版本号，是一个64位无符号整形
每个Node自己有一份Cluster.currentEpoch、MySelf.configEpoch、其他Node.configEpoch，详见文档。
每个Master有自己的ConfigEpoch且在整个Cluster中唯一
Slave的ConfigEpoch随其Master
Cluster.currentEpoch，该值等于所有Node中最大的ConfigEpoch的值
Master的ConfigEpoch初始值是0，也就是说Cluster.CurrentEpoch的初始值也是0
Node之间Gossip传输消息时，Receiver发现Sender的ConfigEpoch比自己大，那么就更新自己的Cluster.CurrentEpoch为该值，随时间收敛，所有Node的Cluster.CurrentEpoch都变成一样。
Slave Promotion Slave的动作下面是总结的在发生Slave Promotion时，Slave做的事情。
Master的动作下面是总结的在发生Slave Promotion时，Master做的事情。
传播Slots的配置Slave赢得选举之后会在己侧更新Slots上的归属信息，然后在定时的PING/PONG中将这个信息传播出去。
PING/PONG总是会携带上Slots所属Master的信息（包括ConfigEpoch）
PING的Reciever如果发现Sender的某个Slot上的Master.ConfigEpoch比自己这里记录的小，那么就会返回UPDATE告诉Sender更新Slots归属信息。
下面是两个规则：
如果一个Slot不属于任何Master，然后有一个Master宣称拥有它，那么就修改己侧的Slots信息把这个Slot关联到这个Master上。
如果一个Slot已经归属一个Master，然后又有一个Master宣称拥有它，那么就看谁的ConfigEpoch大，大的那个赢
Node复活后遇到的问题Node A有两个Slot，然后它死了，它被顶替了，等它复活时发现两个Slot一个被Node B接管，另一个被Node C接管了，那么它：
因为自己的ConfigEpoch已经很旧了，所以它复活后不负责任何Slot
然后它会成为最后一个Slot的Master的Slave
Slave迁移算法Slave迁移时一个自动过程。
举个例子，现在有Master A、B，它们对应的Slave有A1、B1、B2。现在A死了，A1顶替上去，不过这个时候A1就是一个光棍Master（它没有Slave），B有富余的Slave（B1和B2），把其中一个匀给A1当Slave。
这个过程不需要共识，因为只是修改Slave的归属，也不会修改ConfigEpoch。
Slave迁移有两个规则：
当有多个Slave富余时，选择NodeID字典顺最小的那个来迁移
只有当Master的Slave数量>=cluster-migration-barrier时，才会挑选它的Slave做Migration
两个跳过共识修改ConfigEpoch的操作下面两个操作比较危险，最好确定一个成功后再执行另一个：
CLUSTER_FAILOVER TAKEOVER（手动Failover）直接将一个Slave提升为Master，不需要大多数Master同意。
Slot Migration同样不需要大多数Master同意。
所以就有可能出现同一个Slot有两个相同ConfigEpoch的Master宣称由自己负责，这种冲突的解决算法是：
如果Master A发现Master B也宣称了对Slot X的主权，并且两者的ConfigEpoch一样
如果Master A的NodeID的字典顺比Master B的小
那么Master A就把己侧的CurrentEpoch+1，同时ConfigEpoch改成和CurrentEpoch一样
Node重制略，见文档。
移除Node略，见文档。
一些自问自答Q：ConfigEpoch何时变化？
A：Slave Promotion时、手动Failover时、Slot Migration时
Q：ConfigEpoch怎么变化？
A：Node->ConfigEpoch = Cluster->CurrentEpoch + 1，结果也就是Cluster->CurrentEpoch加1了。源码见这里。
Q：两个Master的ConfigEpoch一样怎么办？
A：这个会出现在两个Slave同时Promotion时，解决办法是NodeID字典序比较小的那个会再一次Bump ConfigEpoch，源码见这里。
Q：ConfigEpoch有什么用？
A：当有两个Master宣称自己拥有同一个/批Slot时，ConfigEpoch大的那个赢，因为大的那个代表最新信息，其他Node只会采用赢的那方所宣称的信息。
Q：CurrentEpoch有什么用？
A：1）用来判定Node所获得的Cluster信息的新旧。2）当Node要变更ConfigEpoch时派用处。
参考资料官方文档：
Redis Cluster Spec - Configuration handling, propagation, and failovers
下面是饿了么工程师写的文章，比较透彻：
Redis Cluster 原理与管理
下面是两篇阿里工程师的：
深入理解redis cluster的failover机制
深入解析redis cluster gossip机制
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/37262.html
摘要：本笔记是对的归纳总结状态转换图每个在本地维护了一张其他的状态表，并根据算法更新这张表里的的状态修改状态表里的的状态为在文档中称之为，不需要共识大多数同意。下面是状态转换图，例举的是观察的例子少数派和多数派多数派拥有多数的一方，可含有。 本笔记是对Redis Cluster Spec - Failure Detection的归纳总结 状态转换图 每个Node在本地维护了一张其他Node...
摘要：集群中的每个成员，无论是主副本还是次级副本，都管理哈希槽的一个子集。在由三个主节点组成的最小的集群中，每个主节点都有一个从属节点为了至少能保证最低程度的故障转移，每个主节点分配一个范围在至之间的哈希槽。 showImg(https://segmentfault.com/img/remote/1460000018405753?w=2350&h=1000); 介 绍 Redis（REmo...
摘要：集群中的每个成员，无论是主副本还是次级副本，都管理哈希槽的一个子集。在由三个主节点组成的最小的集群中，每个主节点都有一个从属节点为了至少能保证最低程度的故障转移，每个主节点分配一个范围在至之间的哈希槽。 showImg(https://segmentfault.com/img/remote/1460000018405753?w=2350&h=1000); 介 绍 Redis（REmo...
摘要：命令传播当主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致时，让主从服务器的数据库重新回到一致状态。而与之间则只创建命令连接。 复制 我们可以执行SLAVEOF命令或者设置slaveof选项，让一个服务器去复制(replicate)另一个服务器，复制数据的服务器会变成另一台服务器的从服务器，二者保持相同的数据。以后在主服务器上设置键值会自动同步数据到从服务器上。 复制功...
摘要：通过作为版本号来实现集群配置的一致性。配置信息的一致性主要依靠和，两者除了不同，其余字段语义均相同，消息体为数据。每一个节点向其他节点较为频繁的周期性发送消息和接受响应。同一样，具备完整的节点故障发现故障状态一致性保证主备切换机制。 Redis3.0以后，节点之间通过去中心化的方式提供了完整的sharding(数据分片)、replication(复制机制、Cluster具备感知准备的能...
阅读 1157·2021-09-10 10:51
阅读 2660·2019-08-30 15:54
阅读 3211·2019-08-29 17:11
阅读 802·2019-08-29 16:44
阅读 1242·2019-08-29 13:47
阅读 973·2019-08-29 13:47
阅读 1374·2019-08-29 12:23
阅读 904·2019-08-28 18:18
