Redis Cluster：拓扑结构、一致性达成、数据分片、客户端路由、分片迁移、failover、故障发现、故障确认、slave选举 、Gossip、Ping/Pong、《深入分布式缓存》读书笔记

前言

本文主要内容：

关键字：

内容为《深入分布式缓存：从原理到实践》的相关读书笔记。

Redis Cluster

Redis ClusterRedis 3.0之后，节点之间通过去中心化的方式提供了完整的sharding、replication（复制机制仍复用原有机制，只是cluster具备感知主备的能力）、failover解决方案，称为Redis Cluster。即，将proxy/sentinel的工作融合到了普通的Redis节点里。本小节介绍在Redis Cluster这种新的模式下，水平拆分、故障转移等需求的实现方式。

拓扑结构

一个Redis Cluster由多个Redis节点组构成。不同节点组服务的数据无交集，即每一个节点组对应数据sharding的一个分片。节点组内部分为主备两类节点，两者数据准实时一致，通过异步化的主备复制机制保证。一个节点组有且仅有一个master节点，同时有0到多个slave节点。只有master节点对用户提供写服务，读服务可以由master或者slave提供。

该示例下，key-value数据全集被分成了5份，即5个slot（实际上Redis Cluster总共有16384个slot，每个节点服务一部分slot，这里为了讲述方便，以5个slot为例）。A和B分别为两个master节点，对外提供数据的读写服务，分别负责1/2/3三个slot和4/5两个slot。

A、A1作为主备关系，构成一个节点组，它们之间用主备复制方式同步数据，所以A1作为A的slave节点，仍然持有1/2/3三个slot的数据。同理B1、B2作为B的slave也构成一个节点组。

上述示例中的5个节点间，两两通过Redis Cluster Bus交互，相互交换如下关键信息：
❑ 数据分片（slot）和节点的对应关系；
❑ 集群中每个节点可用状态；
❑ 集群结构（配置）发生变更时，通过一定的协议对配置信息达成一致。数据分片的迁移、故障发生时的主备切换决策、单点master的发现和其发生主备关系的变更等场景均会导致集群结构变化；
❑ publish/subscribe（发布/订阅）功能在cluster版的内部实现所需要交互的信息。

Redis Cluster Bus通过单独的端口进行连接，由于bus是节点间的内部通信机制，交互的是字节序列化信息，而不是client到Redis服务器的字符序列化以提升交互效率。Redis Cluster是一个去中心化的分布式实现方案，客户端可以和集群中的任一节点连接，通过后文所述的交互流程，逐渐地获知全集群的数据分片映射关系。

配置的一致性

对于一个去中心化的实现，集群的拓扑结构并不保存在单独的配置节点上，那么各自为政的节点间如何就集群的拓扑结构达成一致，是Redis Cluster配置机制解决的问题。Redis Cluster通过引入两个自增的epoch变量来使得集群配置在各个节点间达成最终一致。本节首先介绍

配置信息的数据结构

配置信息数据结构Redis Cluster中的每一个节点（Node）内部都保存了集群的配置信息，这些信息存储在clusterState中，它的结构如图所示：

上图的各个变量语义如下：
❑ clusterState记录了从集群中某个节点的视角看来的集群配置状态。
❑ currentEpoch表示整个集群中的最大版本号，集群信息每变更一次，该版本号都会自增以保证每个信息的版本号唯一。
❑ nodes是一个列表，包含了本节点所知的集群所有节点的信息（clusterNode），其中也包含本节点自身。
❑ clusterNode记录了每个节点的信息，其中比较关键的包括该信息的版本epoch，该版本信息的描述