碾压阿里面试官!RedisCluster集群全网最全知识点!

面试官眼神轻蔑，好像觉得我的应用很low，问道：为什么需要Redis Cluster？

• 并发量
  redis 本身 10w/s，但我们的业务已经需要100 w/s 了
• 数据量
  一个 redis 及其内存 16~256G，但我们的业务就是强，需要 500G 了

解决问题的办法不止于简单地加机器。

并发量大了 =》 主从复制解决 =》主从稳定性 =》哨兵解决 =》单节点的写能力、存储能力、动态扩容都很麻烦 =》集群Cluster解决。

Redis Cluster集群模式具有高可用、可扩展性、分布式、容错等特性，在 3.0 闪亮发布。

那你介绍下Redis Cluster的架构？

• 单机架构
  

• 分布式架构
  

• Redis Cluster 架构
  节点
  meet
  指派槽
  复制

• 节点
  

• meet
  
  

• 指派槽

• 客户端与指派槽

Redis Cluster特性：
复制、高可用、分片

Redis分布式服务端及客户端启动

修改两个redis的配置文件redis.conf
修改端口一个为6379，另一个为6380
通过配置文件启动redis-server
redis-server ${redis[0-1]}的${redis.conf}

集群 V.S 分布式

• 分布式：不同的业务模块拆分到不同机器，解决高并发的问题。 工作形态 redis服务器各工作方式不同一般称为Redis分布式

• 集群（cluster）
  同一个业务部署在多台机器上，提高系统可用性。是物理形态,一般称Tomcat集群。集群就是一组计算机，它们作为整体向用户提供一组网络资源， 这些单个的计算机系统就是集群的节点(node)。
  集群可能运行着一个或多个分布式系统，也可能根本没有运行分布式系统；分布式系统可能运行在一个集群上，也可能运行在不属于一个集群的多台（2台也算多台）机器上。

集群提供了以下关键的特性：

• 可扩展性
• 高可用性
• 负载均衡
• 错误恢复

分布式与集群的联系与区别：

• 分布式即分开部署。集群指的是将几台服务器集中在一起，实现同一业务
• 分布式的每一个节点，都可以做集群，而集群并不一定就是分布式的

比如客户端有10个用户，同时分别发送了1个请求，若不是集群，则这10个请求需要并行在一台机器上处理，如果每个请求都是1s，则有一人要等待10s，有一个人等待9s…
而在集群下，10个任务并分发到10台机器同时进行，则每人等待时间都是1s。

Redis Cluster 安装配置

两种安装：

原生命令安装

理解架构

1.配置开启节点
2. meet
3.指派槽
4.主从

官方工具安装

Redis 3.0后，节点之间通过去中心化，提供了完整的sharding、replication（复制机制仍使用原有机制，并且具备感知主备的能力）、failover解决方案，称为Redis Cluster。
即：将proxy/sentinel的工作融合到了普通Redis节点。

Redis Cluster 集群架构

Redis Cluster采用无中心结构，每个节点都可以保存数据和整个集群状态，每个节点都和其他所有节点连接。要让集群正常运作至少需要三个主节点，即Cluster 至少为6个才能保证组成完整高可用的集群，三主三从：

• 主节点分配槽，处理客户端的命令请求
• 从节点可用在主节点故障后，顶替主节点
  

集群架构为拓扑结构。一个Redis Cluster由多个Redis节点组成。不同的节点组服务的数据无交集，每个节点对应数据sharding的一个分片。

节点组内部分为主备2类，对应master和slave。两者数据准实时一致，通过异步的主备复制保证。

一个节点组有且仅有一个master，同时有0到多个slave。只有master对外提供写服务，读服务可由master/slave提供

• Redis Cluster结构
  
  key-value全集被分成了5份，5个slot（实际上Redis Cluster有 16384 [0-16383] 个slot，每个节点服务一段区间的slot，这里面仅仅举例）。A和B为master节点，对外提供写服务。分别负责1/2/3和4/5的slot。A/A1和B/B1/B2之间通过主备复制的方式同步数据。

上述的5个节点，两两通过Redis Cluster Bus交互，相互交换如下的信息：

• 数据分片（slot）和节点的对应关系
• 集群中每个节点可用状态
• 集群结构发生变更时，通过一定的协议对配置信息达成一致。数据分片的迁移、主备切换、单点master的发现和其发生主备关系变更等，都会导致集群结构变化
• publish/subscribe（发布/订阅）功能，在Cluster版内部实现所需要交互的信息

Redis Cluster Bus通过单独的端口进行连接，由于Bus是节点间的内部通信机制，交互的是字节序列化信息。相对Client的字符序列化来说，效率较高。

Redis Cluster是一个去中心化的分布式实现方案，客户端和集群中任一节点连接，然后通过后面的交互流程，逐渐的得到全局的数据分片映射关系。

说说Redis Cluster 的优点？

• 去中心化
• 可扩展性
  数据是按槽分配的，节点之间数据共享，节点动态的添加和删除
• 高可用性
  部分节点不可用时，集群仍是可用的，因为从节点作为副本提供了数据的备份保障
• 自动故障转移
  节点之间投票选举，从升级为主

说说Redis Cluster 的缺点？

• 数据通过异步复制，无法保证数据强一致性
• 集群环境搭建略微复杂。

2 配置的一致性

对于去中心化的实现，集群的拓扑结构并不保存在单独的配置节点上，后者的引入同样会带来新的一致性问题。
那么各自为政的节点间，如何对集群的拓扑达成一致，是Redis Cluster配置机制要解决的问题。
Redis Cluster通过引入2个自增的epoch变量，来使得集群配置在各个节点间最终达成一致。

2.1 配置信息数据结构

Redis Cluster中的每个节点(Node)都保存了集群的配置信息，并且存储在clusterState中，结构如下

• clusterState 记录了从集群中某个节点视角，来看集群配置状态
• currentEpoch 表示整个集群中最大的版本号，集群信息每变更一次，改版本号都会自增
• nodes 是一个列表，包含了本节点所感知的，集群所有节点的信息（clusterNode），也包含自身的信息。
• clusterNode 记录了每个节点的信息，其中包含了节点本身的版本 Epoch；自身的信息描述：节点对应的数据分片范围（slot）、为master时的slave列表、为slave时的master节点
• 每个节点包含一个全局唯一的NodeId
• 当集群的数据分片信息发生变更（数据在节点间迁移时），Redis Cluster 仍然保持对外服务
• 当集群中某个master宕机，Redis Cluster 会自动发现，并触发故障转移的操作。将master的某个slave晋升为新的 master。

由此可见，每个节点都保存着Node视角的集群结构。它描述了数据的分片方式，节点主备关系，并通过Epoch 作为版本号实现集群结构信息的一致性，同时也控制着数据迁移和故障转移的过程。

2.2 信息交互

去中心化的架构不存在统一的配置中心。在Redis Cluster中，这个配置信息交互通过Redis Cluster Bus来完成（独立端口）。Redis Cluster Bus 上交互的信息结构如下：

• Redis Cluster 交互信息数据结构
  
  clusterMsg 中的type指明了消息的类型，配置信息的一致性主要依靠PING/PONG。每个节点向其他节点频繁的周期性的发送PING/PONG消息。
  对于消息体中的 Gossip部分，包含了sender/receiver 所感知的其他节点信息，接受者根据这些Gossip 跟新对集群的认识。

对于大规模的集群，如果每次PING/PONG 都携带着所有节点的信息，则网络开销会很大。此时Redis Cluster 在每次PING/PONG，只包含了随机的一部分节点信息。由于交互比较频繁，短时间的几次交互之后，集群的状态也会达成一致。

2.3 一致性的达成

当Cluster 结构不发生变化时，各个节点通过gossip 协议在几轮交互之后，便可以得知Cluster的结构信息，达到一致性的状态
但是当集群结构发生变化时（故障转移/分片迁移等），优先得知变更的节点通过Epoch变量，将自己的最新信息扩散到Cluster，并最终达到一致。

clusterNode 的Epoch描述的单个节点的信息版本；

clusterState 的currentEpoch描述的是集群信息的版本，它可以辅助Epoch 的自增生成
因为currentEpoch 是维护在每个节点上的，在集群结构发生变更时，Cluster 在一定的时间窗口控制更新规则，来保证每个节点的currentEpoch都是最新的

更新规则

• 当某个节点率先知道了变更时，将自身的currentEpoch 自增，并使之成为集群中的最大值
  再用自增后的currentEpoch 作为新的Epoch 版本
• 当某个节点收到了比自己大的currentEpoch时，更新自己的currentEpoch
• 当收到Redis Cluster Bus 消息中的某个节点的Epoch > 自身的时，将更新自身的内容
• 当Redis Cluster Bus 消息中，包含了自己没有的节点时，将其加入到自身的配置中

上述的规则保证了信息的更新是单向的，最终朝着Epoch更大的信息收敛
同时Epoch也随着currentEpoch的增加而增加，最终将各节点信息趋于稳定

sharding

不同节点分组服务于相互无交集的分片（sharding）
Redis Cluster 不存在单独的proxy或配置服务器
所以需要将客户端路由到目标的分片

1、数据分片（slot）

Redis Cluster 将所有的数据划分为16384 [0-16383] 个分片，每个分片负责其中一部分
每一条数据（key/value）根据key值,通过数据分布算法（一致性哈希）映射到16384 个slot中的一个

数据分布算法

slotId = crc16(key) % 16384

客户端根据slotId 决定将请求路由到哪个Redis 节点。
Cluster 不支持跨节点的单命令，如：sinterstore，如果涉及的2个key对应的slot 在不同的Node，则执行失败。
通常Redis的key都是带有业务意义的，如：

• Product:Trade:20180890310921230001
• Product:Detail:20180890310921230001

当在集群中存储时，上述同一商品的交易和详情可能会存储在不同的节点上，进而对于这2个key 不能以原子的方式操作。
为此，Redis引入了HashTag的概念，使得数据分布算法可以根据key 的某一部分进行计算，让相关的2 条记录落到同一个数据分片

商品交易记录key：Product:Trade:{20180890310921230001}
商品详情记录key：Product:Detail:{20180890310921230001}

Redis 会根据 {} 之间的字符串作为数据分布式算法的输入。

2、客户端的路由

Redis Cluster的客户端相比单机Redis 需要具备路由语义的识别能力，且具备一定的路由缓存能力
当Client 访问的key 不在当前Redis 节点的slots中，Redis 会返回给Client 一个moved命令。并告知其正确的路由信息

当Client 接收到moved 后，再次请求新的Redis时，此时Cluster 的结构又可能发生了变化。此时有可能再次返回moved
Client 会根据moved响应，更新其内部的路由缓存信息，以便后续的操作直接找到正确的节点，减少交互次数。

当Cluster 在数据重新分布过程中时，可以通过ask 命令控制客户端的路由，如下所示：

​​​​上图中，slot 1 需要迁移到新节点上，此时如果客户端已经完成迁移的key，节点将相应ask 告知客户端想目标节点重试。

ask命令和moved 命令的不同

• moved 会更新Client数据路由
• ask 只是重定向新节点，但是后续的相同slot 仍会路由到旧节点

迁移的过程可能会持续一段时间，这段时间某个slot 的数据，同时可能存在于新旧 2 个节点。
由于move 操作会使Client 的路由缓存变更，如果新旧节点对于迁移中的slot 所有key 都回应moved，客户端的路由缓存会频繁变更。因此引入ask 类型消息，将重定向和路由缓存分离

3 分片的迁移

在一个稳定的Redis Cluster 中，每个slot 对应的节点都是确定的。在某些情况下，节点和分片需要变更：

新的节点作为master加入；

某个节点分组需要下线；

负载不均衡需要调整slot 分布。

此时需要进行分片的迁移，迁移的触发和过程控制由外部系统完成。Redis Cluster 只提供迁移过程中需要的原语，包含下面 2 种：

节点迁移状态设置：迁移前标记源/目标节点。
key迁移的原子化命令：迁移的具体步骤。

下面的Demo会介绍slot 1 从节点A 迁移到B的过程。

1、向节点B发送状态变更命令，将B的对应slot 状态置为importing。

2、向节点A发送状态变更命令，将A对应的slot 状态置为migrating。

3、针对A上的slot 的所有key，分别向A 发送migrate 命令，告知A 将对应的key 迁移到B。

当A节点的状态置为migrating 后，表示对应的slot 正在从A迁出，为保证该slot 数据的一致性。A此时提供的写服务和通常状态下有所区别，对于某个迁移中的slot：

如果Client 访问的key 尚未迁出，则正常的处理该key；

如果key已经迁出或者key不存在，则回复Client ASK 信息让其跳转到B处理；

当节点B 状态变成importing 后，表示对应的slot 正在向B迁入。即使B 能对外提供该slot 的读写服务，但是和通常情况下有所区别：

当Client的访问不是从ask 跳转的，说明Client 还不知道迁移。有可能操作了尚未迁移完成的，处在A上面的key，如果这个key 在A上被修改了，则后续会产生冲突。

所以对于该slot 上所有非ask 跳转的操作，B不会进行操作，而是通过moved 让Client 跳转至A执行。

这样的状态控制，保证了同一个key 在迁移之前总是在源节点执行。迁移后总是在目标节点执行，从而杜绝了双写的冲突。迁移过程中，新增加的key 会在目标节点执行，源节点不会新增key。使得迁移有界限，可以在某个确定的时刻结束。

单个key 的迁移过程可以通过原子化的migrate 命令完成。对于A/B的slave 节点，是通过主备复制，从而达到增删数据。

当所有key 迁移完成后，Client 通过 cluster setslot 命令设置B的分片信息，从而包含了迁入的slot。设置过程中会让Epoch自增，并且是Cluster 中的最新值。然后通过相互感知，传播到Cluster 中的其他节点。

failover

同Sentinel 一样，Redis Cluster 也具备一套完整的故障发现、故障状态一致性保证、主备切换机制。

1、failover的状态变迁

1）故障发现：当某个master 宕机时，宕机时间如何被集群其他节点感知。

2）故障确认：多个节点就某个master 是否宕机如何达成一致。

3）slave选举：集群确认了某个master 宕机后，如何将它的slave 升级成新的master；如果有多个slave，如何选择升级。

4）集群结构变更：成功选举成为master后，如何让整个集群知道，以更新Cluster 结构信息。

2、故障发现

Redis Cluster 节点间通过Redis Cluster Bus 两两周期性的PING/PONG 交互。当某个节点宕机时，其他Node 发出的PING消息没有收到响应，并且超过一定时间（NODE_TIMEOUT）未收到，则认为该节点故障，将其置为PFAIL状态（Possible Fail）。后续通过Gossip 发出的PING/PONG消息中，这个节点的PFAIL 状态会传播到集群的其他节点。

Redis Cluster 的节点两两通过TCP 保持Redis Cluster Bus连接，当对PING 无反馈时，可能是节点故障，也可能是TCP 链接断开。如果是TCP 断开导致的误报，虽然误报消息会因为其他节点的正常连接被忽略，但是也可以通过一定的方式减少误报。Redis Cluster 通过 预重试机制 排除此类误报：当 NODE_TIMEOUT/2 过去了，但是还未收到响应，则重新连接重发PING 消息，如果对端正常，则在很短的时间内就会有响应。

3、故障确认

对于网络分隔的情况，某个节点（B）并没有故障，但是和A 无法连接，但是和C/D 等其他节点可以正常联通。此时只会有A 将 B 标记为PFAIL 状态，其他节点认为B 正常。此时A 和C/D 等其他节点信息不一致，Redis Cluster 通过故障 确认协议 达成一致。

集群中每个节点都是Gossip 的接收者，A 也会接收到来自其他节点的Gossip 消息，被告知B 是否处于PFAIL 状态。当A收到来气其他master 节点对于 B 的PFAIL 达到一定数量后，会将B的PFAIL 状态升级为 FAIL 状态。表示B 已经确认为故障态，后面会发起slave 选举流程。

A节点内部的集群信息中，对于B的状态从PFAIL 到 FAIL 的变迁，如下图所示：

4、slave选举

先看配置项，确认该从节点是否有资格能晋升主节点。
再看偏移量，越大说明数据越多，越会成为主节点。
如果相同，看 row_id，小的竞选成功。
上图中，B是A的master，并且B 已经被集群公认是FAIL态了，那么A 发起竞选，期望成为新的master。

如果B有多个slave （A/E/F）都认知到B 处于FAIL 状态了，A/E/F 可能会同时发起竞选。当B的slave 个数 >= 3 时，很有可能产生多轮竞选失败。为了减少冲突的出现，优先级高的slave 更有可能发起竞选，从而提升成功的可能性。这里的优先级是slave的数据最新的程度，数据越新的（最完整的）优先级越高。

slave 通过向其他master发送FAILVOER_AUTH_REQUEST 消息发起竞选，master 收到后回复FAILOVER_AUTH_ACK 消息告知是否同意。slave 发送FAILOVER_AUTH_REQUEST 前会将currentEpoch 自增，并将最新的Epoch 带入到FAILOVER_AUTH_REQUEST 消息中，如果自己未投过票，则回复同意，否则回复拒绝。

5、结构变更通知

当slave 收到过半的master 同意时，会替代B 成为新的master。此时会以最新的Epoch 通过PONG 消息广播自己成为master，让Cluster 的其他节点尽快的更新拓扑结构。

当B 恢复可用之后，它手续爱你仍然认为自己是master，但逐渐的通过Gossip 协议得知A 已经替代了自己，然后降级为A的slave。

可用性和性能

Redis 集群的一致性保证（guarantee）

Redis 集群不保证数据的强一致性（strong consistency）： 在特定条件下， Redis 集群可能会丢失已经被执行过的写命令。

异步复制

使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个原因。

1. 客户端向主节点 B 发送一条写命令
2. B 执行写命令，并向客户端返回命令回复
3. B 将刚执行的写命令复制给它的从节点 B1 、 B2 和 B3

主节点对命令的复制工作发生在返回命令回复之后，因为若每次处理命令请求都需要等待复制操作完成， 则主节点处理命令请求速度将极大降低，必须在性能和一致性之间取舍！

如果真的有必要， Redis 集群可能会在未来版本提供同步（synchronou）执行写命令的方法。

网络分裂

Redis 集群另外一种可能会丢失命令的情况是， 集群出现网络分裂（network partition）， 并且一个客户端与至少包括一个主节点在内的少数（minority）实例被孤立。

假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点：A 、B 、C 为主节点， A1 、B1 、C1 分别为三个主节点的从节点， 一个客户端 Z1 。

假设集群中发生网络分裂， 那么集群可能会分裂为两方， 大多数（majority）的一方包含节点 A 、C 、A1 、B1 和 C1 ， 而少数（minority）的一方则包含节点 B 和客户端 Z1 。

在网络分裂期间， 主节点 B 仍然会接受 Z1 发送的写命令：

• 若网络分裂时间很短， 则集群会继续正常运行
• 但若网络分裂出现时间长， 使得大多数一方将 B1 设置为新master， 并使用 B1 代替了原主节点 B ， 则 Z1 发送给主节点 B 的写命令将丢失。

在网络分裂出现期间， Z1 可以向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项：

• 对于大多数一方来说， 如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群， 那么集群会将这个主节点视为下线， 并使用从节点来代替这个主节点继续工作
• 对于少数一方， 如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群， 那么它将停止处理写命令， 并向客户端报告错误

Redis Cluster 还提供了一些方法可以提升性能和可用性。

1、Redis Cluster的读写分离

对于读写分离的场景，应用对于某些读请求允许舍弃一定的数据一致性，以换取更高的吞吐量。此时希望将读请求交给slave处理，以分担master的压力。

通过分片映射关系，某个slot 一定对应着一个master节点。Client 通过moved 命令，也只会路由到各个master中。即使Client 将请求直接发送到slave上，也会回复moved 到master去处理。

为此，Redis Cluster 引入了readonly 命令。Client 向slave发送该命令后，不再moved 到master处理，而是自己处理，这成为slave的readonly 模式。通过readwrite命令，可以将slave的readonly模式重置。

2、master单点保护

假如Cluster 的初始状态如下所示：

上图中A、B两个master 分别有自己的slave，假设A1 发生宕机，结构变为如下所示：

此时A 成为了单点，一旦A 再次宕机，将造成不可用。此时Redis Cluster 会把B 的某个slave （如 B1 ）进行副本迁移，变成A的slave。如下所示：

这样集群中每个master 至少有一个slave，使得Cluster 具有高可用。集群中只需要保持 2*master+1 个节点，就可以保持任一节点宕机时，故障转移后继续高可用。