Redis_Cluster的Failover设计.pptVIP

张海雷 Redis Cluster的Failover设计 Redis Cluster简介 服务端shard，并且支持请求的路由跳转 使用哈希槽分片，支持在线扩容 去中心化设计，Gossip用于节点感知 一致性算法采用类似Raft，但有做改进 Gossip Gossip(谣言传播算法)用于节点感知，新节点加入以后传播给整个集群中的所有节点。 实现方式：节点之间通过ping/pong的方式交换信息。关键点是在发送ping的时候，将已知的节点列表附带过去。对方收到以后，和自己的节点列表比对，找出不存在的作为新节点添加到节点列表中。 考虑到集群规模比较大，在Gossip每次都是随机挑选5个节点，然后再从这五中找出一个最不经常联系(ping)的节点发送ping，并且附带节点的数量=3。按照这样的设计作者说能支撑1000节点的集群。 上述随机挑选节点的方式。有可能导致某些节点“饥饿”。 解决方式是定时检查所有节点，如果距上次收到Pong超过cluster-node-timeout的一半以上的时间没有发送Ping，则补发Ping Gossip不仅用做节点感知，也用做失败判定 Gossip演示 A B Meet A B C A B A B A B A B C Meet A C B 一致性算法 Raft算法简介。/raft/ Cluster Epoch(纪元) Redis集群采用去中心化管理。如果要配置一致，就得需要一致性算法来保证。Redis集群采用类似Raft算法，但有做改进。 什么是Epoch？ Redis集群使用一种类似Raft算法中“term”的概念，我们这里叫做epoch。Epoch是一个只增的版本号。每当有事件发生，epoch向上增长。 这里的事件是指节点加入、failover等 Cluster Epoch(纪元) Current Epoch用于集群的epoch，代表集群的版本。 Config Epoch，每个master都有config Epoch代表Master的版本 每个新加入的节点，current Epoch初始为0，通过ping/pong消息交换的话，如果发送节点的epoch高于自己的，则将自己的currentEpoch更新为发送者的。经过N轮消息交换以后，每个节点的current epoch保持一致。 Current Epoch用于failover。后续会介绍。 configEpoch 前面介绍过，configEpoch代表master的版本 从名字上看，他是解决配置冲突的，比如slot冲突（比如slot迁移）、failover(slave晋升以后的角色转换) 每个master的configEpoch必须不同，当发生配置冲突以后，采用高版本的配置。 其实仅就Failover来说的话，不同master的configEpoch相同也没有问题。 但如果发生slot migrate的话，就会有问题，特别是slot migrate和failover赶在一起的话。 每个新加入的节点，configEpoch都是0。 Redis提供了解决冲突的办法，节点之间消息交换过程中，会把自己的currentEpoch和configEpoch带过去，如果发现发送者的configEpoch和自己的configEpoch相同，则将自己的Epoch+1，经过N轮以后使每个master的configEpoch不一样 Slave也有configEpoch，是通过master交互得到的Master的configEpoch 演示configEpoch冲突 A0 B0 C0 D0 A0 B1 C0 D0 A-B A1 B1 C0 D0 C-A 初始 B-A A2 B1 C0 D0 D-C A2 B1 C1 D0 B-C A2 B1 C2 D0 AC A2 B1 C3 D0 Fail Over 失败判定 Leader选举 失败判定 PFail，节点之间通过心跳检测对方节点是否存活，如果心跳超时，则标记对方节点为PFail状态 前面提过Gossip，在ping/pong交换信息的时候，会随机携带自己已知节点的信息过去，这样处于Pfail状态的节点会通过传播给整个集群。 假设集群中有A、B和C三个节点,A是Master，ApingB，心跳超时，会将B标记为 Pfail并通过Gossip传播给C 。C收到A对B的失败报告以后，放在B节点的失败报告链表中 细节实现一 实现细节二 Pfail-Fail Pfail-Fail的转换，是通过一种协议的方式。大于集群中Mast