IT技术分享 2019-07-11 15:11:40
来源:网络
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迁移有两个规则:
cluster-migration-barrier
两个跳过共识修改ConfigEpoch的操作
下面两个操作比较危险,最好确定一个成功后再执行另一个:
CLUSTER_FAILOVER TAKEOVER
所以就有可能出现同一个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时派用处。
需要的Java架构师方面的资料可以关注之后私信哈,回复“资料”领取免费架构视频资料,记得要点赞转发噢!!!