一、Redis Cluster 简介
Redis3.0之后，节点之间通过去中心化的方式提供了完整的sharding（分片）、replication（复制）、failover解决方案，称为 Redis Cluster。
二、拓扑结构
一个Redis Cluster由多个节点组构成。不同节点组服务的数据无交集，即每一个节点组对应数据sharding的一个分片，如节点A和节点B；A和A1作为主备关系，构成一个节点组，两者数据准实时一致，通过异步化的准备复制机制保证，一个节点组有且只有一个master节点，但可以有0到多个slave节点，只有master节点对用户提供写服务，至于读服务主备节点都可以做。
上图中有5个节点，它们之间通过Redis Cluster Bus 进行交互，交换以下信息：
1 数据分片（slot）和节点的对应关系；
2 集群中每个节点可用状态；
3 集群结构（配置）发生变更时，通过gossip协议对配置信息达成一致。（数据分片的迁移、故障发生时的主备切换决策、单点master的发现和其他发生主备关系的变更等场景均会导致集群结构变化）
4 publish / subscribe （发布/订阅）功能在cluster版的内部实现所需要交互的信息。
通过拓扑结构可以发现，Redis Cluster 是一个去中心化的分布式实现方案，客户端可以和集群中的任意节点连接，然后通过gossip的特性，逐渐获知全集群的数据分片映射关系。
小知识：Redis Cluster Bus通过单独的端口进行连接，由于bus是节点间的内部通信机制，交互的是字节序列化信息，而不是client请求Redis服务器的字符序列化信息，这样做的目的是提升传输效率。
三、配置的一致性
对于一个去中心化的实现，各自为政的节点如何就集群的拓扑结构达成一致，是 Redis Cluster 配置机制解决的问题。下面介绍配置信息数据结构、交互信息结构，以及如何实现配置信息一致。
1 配置信息数据结构
Cluster State 记录了以集群中某个节点的视角，所看到的集群配置状态，其中：
currentEpoch 表示集群中的最大版本号，集群信息每变更一次，该版本号都会自增以保证每个信息的版本号是唯一的；
nodes 是一个列表，包含了本节点所感知到的集群中所有节点的信息（Cluster Node），当然也包含本节点自身；
当集群的数据分片发生变更，例如分片在节点组之间迁移的时候，Redis Cluster仍然保持着对外服务，在迁移的过程中，通过“数据分片相关状态”的一组变量来管控迁移过程。；
当集群中某个master出现宕机时，Redis Cluster会自动发现并触发故障转移操作，将宕机master的某个slave升级为新的master，这个过程中同样包含“failover相关状态”的一组变量来控制故障转移的一系列过程。
Cluster Node 记录了每个节点的信息，其中比较关键的是该信息的版本epoch，该结构主要描述了：该节点对应的数据分片（slot）、当该节点为master时的slave节点列表 以及 该及诶单为slave时对应的master节点，每个节点包含一个全局唯一的NodeId。
从上图空间，每个节点都保存了从它的视角所看到的集群结构，该结构描述了数据的分片方式、节点主备关系，并通过epoch作为版本号实现集群结构信息的一致性，同时也控制着数据迁移和故障转移的过程。
2 信息交互
因为去中心化的架构下不存在统一的配置中心，所以各个节点对整个集群状态的认知来自于节点间的信息交互，这个交互是通过之前提到过的Redis Cluster Bus来完成的，在Bus上交互的信息结构如下图所示：
ClusterMsg的type字段指明了消息的类型，配置信息达成最终一致性主要依靠PING和PONG两种类型的msg，两者除了type不同之外，其余字段语义信息一致，其消息体即上图所示的gossip数据。
每一个节点向其它所有节点较为频繁地周期性发送PING消息，同时接收到对应的PONG回应。在这些消息的gossip部分，包含了发送者节点（或响应节点）所知的集群其它节点信息。接收节点根据这些gossip信息更新自己对于集群结构的认识。Redis Cluster每次PING / PONG包中，只包含全集群的部分节点信息，节点随机选取，以此控制网络流量。由于交互较为频繁，在很短时间内交互几次之后，集群状态以Gossip协议的方式被扩散到了集群中的所有节点。
3 一致性的达成
当集群结构不发生变化的时候，通过gossip机制可以很快辐射到集群中的所有节点，并且达到最终一致状态。但是，故障转移、分片迁移等场景也会导致集群结构变更，变更的信息需要各个节点自行协调，优先得知结构变更的节点通过epoch变量将自己的最新信息扩散到整个集群，达到最终一致。需要注意的是：
配置信息Cluster Node的epoch属性描述的粒度是单个节点，即某个节点的数据分片、主备信息版本；
配置信息的Cluster State的currentEpoch属性的粒度是整个集群，它的存在用来辅助epoch自增的生成，由于currentEpoch信息也是维护在各个节点自身，所以集群结构发生变化时，通过一定的时间窗口控制和更新规则来保证每个节点看到的currentEpoch都是最新的。
集群信息的更新遵循以下规则：
当A节点率先知道了集群结构变更，这个节点将currentEpoch自增，这时候A的currentEpoch就成为了集群中的最大值，在用自增厚的currentEpoch作为新的epoch版本；
当B节点收到了比自己大的currentEpoch时，B会更新自己节点的currentEpoch值以保持最新；
当收到Redis Cluster Bus消息中某个节点信息的epoch值大于接收者自己内部配置信息存储的值时，意味着自己的信息太旧了，此时会将自己的映射信息更新为消息的内容；
当收到Redis Cluster Bus消息中某个节点信息未包含在接收节点的内部配置信息时，意味着接收者尚未意识到消息所指节点的存在，此时接收者直接将消息的信息添加到自己的内部配置信息中。
上述规则保证了信息更新始终是单向的，始终朝着epoch值更大的信息收敛，同时epoch值也随着每次集群配置变更时currentEpoch的自增而单向增加，确定了各节点信息更新的方向稳定。
