redis集群(二)

上一篇博客我们讲了搭建集群和节点通信,这节课我们来讲一下如果节点出问题了,redis内部是如何来进行故障转移的

1.发现有问题的节点

上节课我们也提到了redis节点是怎么通信的"ping-pong",通信时附加了消息,消息除了槽信息,还有节点状态/节点故障等

 

解释:  节点a发送ping消息给节点b,如果正常情况下, b应该会应答pong消息,在a收到pong消息后,就会更新它与B之间通信时间; 如果节点a与节点b之间通信出现了问题,那么节点a上就会一直记录的是最后通着的时间. 节点a中有一个定时任务,这个任务如果检测到a和b之间通信时间,超过了redis配置文件设置的cluster-node-timeout,那么节点a就认为节点b 宕掉了. a就会更新它对b的状态,变成了下线.

为啥是主节点, 这里是因为集群下只有主节点才会负责读写请求和集群槽等关键信息维护,从节点只是进行主节点数据和状态的复制.

可能你会说,那万一就是单纯a和b链接的时候,网不太好,或者其他原因导致的,实际上节点b并没有宕掉. 其实呢,redis集群对于节点最终是否故障是很严谨的. 对于一个节点判断最终故障并将它退出工作模式,是下面这样的

当节点a判断节点b下线之后, 在a和其他节点ping-pong的时候,也会把这个信息传给节点c,所以b下线这个消息就会不断的传播,c接收到b下线消息之后,会更新自己本地的b节点的clusterNode结构,然后记录下来.然后来触发客观下线,先来判断这个集群中,对于节点b下线的统计,是持有槽的主节点,有没有超过一半的数量都标记了b下线了.如果超过一半,就会向集群中发一条fail消息,让所有的节点都把b标记为客观下线.同时需要在节点b的从节点中选出一个替换它.这就涉及到了选举机制

 在选举之前,会先检查一下从节点有没有资格来作为候选人的.每个节点先来检查一下,它与主节点断线时间,如果断开连接 时间超过了cluster-node-time * cluster-slave-validity-factor,那么当前这个节点就不具备资格了, 第一步就刷下来了.

第二步,有资格的候选人都有了,更新触发故障选举的时间,只有到了这个时间后才能执行后面的路程.这里就有一个延迟触发机制,我不太懂这里,不过说的是复制偏移量越大就证明这个节点优先级越高.

第三步,开始选举. 

 集群中所有持有槽的主节点来选举,只要从节点收到N/2+1个主节点投票,就任务可以替换有故障的主节点了.

第四步,替换主节点

把从节点取消复制,变成主节点,把要替换的主节点的槽委派给自己. 向集群中广播自己pong消息.通知集群中小伙伴.