Redis Cluster是Redis的分布式解决方案，在3.0版本正式推出，有效地解决了Redis分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时，可以采用Cluster架构方案达到负载均衡的目的。在此之前，Redis分布式方案一般有两种：

• 客户端分区方案，优点是分区逻辑可控，缺点是需要自己处理数据路由、高可用、故障转移等问题。
• 代理方案，优点是简化客户端分布式逻辑和升级维护遍历，缺点是加重架构部署复杂度和性能损耗。

 

一、数据分布

1、数据分布理论

分布式数据库首先要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整体数据的一个子集。需要重点关注的是数据分区规则，常见的分区规则有哈希分区和顺序分区两种。

 

由于Redis Cluster采用哈希分区规则，这里我们重点讨论哈希分区，常见的哈希分区规则有几种，下面分别介绍。

1、节点取余分区

使用特定的数据，如Redis的键或用户ID，再根据节点数量N使用公式：hash(key)%N计算出哈希值，用来决定数据映射到哪一个节点上。这种方案存在一个问题：当节点数量变化时，如扩容或收缩节点，数据节点映射关系需要重新计算，会导致数据的重新迁移。这种方式的突出优点是简单性，常用于数据库的分库分表规则，一般采用预分区的方式，提前根据数据量规划好分区数，比如划分为512或1024张表，保证可支撑未来一段时间的数据量，再根据负载情况将表迁移到其他数据库中。扩容时通常采用翻倍扩容，避免数据映射全部被打乱导致全量迁移的情况。

2、一致性哈希分区

一致性哈希分区实现思路是为系统中每个节点分配一个token，范围一般在0~2^32，这些token构成一个哈希环。数据读写执行节点查找操作时，先根据key计算hash值，然后顺时针找到第一个大于等于该哈希值的token节点，如下图所示

 

这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中相邻的节点，对其他节点无影响。但一致性哈希分区存在几个问题：

• 加减节点会造成哈希环中部分数据无法命中，需要手动处理或者忽略这部分数据，因此一致性哈希常用于缓存场景。
• 当使用少量节点时，节点变化将大范围影响哈希环中数据映射，因此这种方式不适合少量数据节点的分布式方案。
• 普通的一致性哈希分区在增减节点时需要增加一倍或减去一半节点才能保证数据和负载的均衡。

正因为一致性哈希分区的这些缺点，一些分布式系统采用虚拟槽对一致性哈希进行改进，比如Dynamo系统。

3、虚拟槽分区

虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中，整数定义为槽（slot）。这个范围一般远远大于节点数，比如Redis Cluster槽范围是0~16383。槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽，如下图所示：

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

当前集群5个节点，每个节点平均大约负责3276个槽。由于采用高质量的哈希算法，每个槽所映射的数据比较均匀，将数据平均划分到5个节点进行数据分区。Redis Cluster就是采用虚拟槽分区。

 

2、Redis数据分区

Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0~16383整数槽内，计算公式：

slot=CRC16（key）&16383。每一个节点负责维护一部分槽以及槽锁映射的键值数据，如下图所示：

Redis虚拟槽分区的特点：

• 解耦数据和节点的关系，简化了节点扩容和收缩难度。
• 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据。
• 支持节点、槽、键之间的映射查询，用于数据路由、在线伸缩等场景。

数据分区是分布式存储的核心，理解和灵活运用数据分区规则对于掌握Redis Cluster非常有帮助。

 

3、集群功能限制

Redis集群相对单机在功能上存在一些限制，需要开发人员提前了解，在使用时做好规避。限制如下：

1）key批量操作支持有限。如mset、mget，目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于执行mset、mget等操作可能存在于多个节点上因此不被支持。

2）key事务操作支持有限。同理只支持多key在同一节点上的事务操作，当多个key分布在不同的节点上时无法使用事务功能。

3）key作为数据分区的最小粒度，因此不能将一个大的键值对象如hash、list等映射到不同的节点。

4）不支持多数据库空间。单机下的Redis可以支持16个数据库，集群模式下只能使用一个数据库空间，即db0.

5）复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。

 

 二、集群搭建

略

三、集群伸缩

Redis集群提供了灵活的节点扩容和收缩方案。在不影响集群对外服务的情况下，可以为集群添加节点进行扩容也可以下线部分节点进行缩容，Redis集群可以实现对节点的灵活上下线控制。其中原理可抽象为槽和对应数据在不同节点之间灵活移动。首先来看之前搭建的集群槽和数据与节点的对应关系，如下图所示：

三个主节点分别维护自己负责的槽和对应的数据，如果希望加入1个节点实现集群扩容时，需要通过相关命令把一部分槽和数据迁移给新节点，如下图所示：

图中每个节点把一部分槽和数据迁移到新的节点6385，每个节点负责的槽和数据相比之前变少了从而达到了集群扩容的目的。

这里故意忽略了槽和数据在节点之间迁移的细节，目的是让重点关注在上层槽和节点分配上来，理解集群的水平伸缩的上层原理：集群伸缩=槽和数据在节点之间的移动。

2、扩容集群

 

扩容是分布式存储最常见的需求，Redis集群扩容操作可分为如下步骤：

1）准备新节点

2）加入集群

3）迁移槽和数据

 

1、准备新节点

需要提前准备好新节点并运行在集群模式下，新节点建议跟集群内的节点配置保持一致，便于管理统一。准备好配置后启动两个节点命令如下：

redis-server conf/redis-6385.conf

redis-server conf/redis-6386.conf

 

启动后的新节点作为孤儿节点运行，并没有其他节点与之通信，集群结构如下图所示。

 

 

 

 

 

 

 

 

 

 

 

 

 

集群内新旧节点经过一段时间的ping/pong消息通信之后，所有节点会发现新节点并将它们的状态保存到本地。

新节点刚开始都是主节点状态，但是由于没有复制的槽，所以不能接受任何读写操作。对于新节点的后续操作我们一般有两种选择：

• 为它迁移槽和数据实现扩容
• 作为其他主节点的从节点负责故障转移

 

3、迁移槽和数据

加入集群后需要为新节点迁移槽和相关数据，槽在迁移过程中集群可以正常提供读写服务，迁移过程是集群扩容最核心的环节

（1）槽迁移计划

槽是Redis集群管理数据的基本单位，首先需要为新节点制定槽的迁移计划，确定原有节点的哪些槽需要迁移到新节点。迁移计划需要确保每个节点负责相似数量的槽，从而保证各节点的数据均匀。例如，在集群中加入6385节点，如下图所示，加入6385节点后，原有节点负责的槽数量从6380变为4096个。

 

槽迁移计划确定后开始逐个把槽内数据从源节点迁移到目标节点。

 

（2）迁移数据

数据迁移过程是逐个槽进行的，每个槽数据迁移的流程如下图所示：

 

流程说明：

1）对目标节点发送cluster setslot{slot}importing{sourceNodeId}命令，让目标节点准备导入槽的数据。

2）对源节点发送cluster setslot{slot}migrating{targetNodeId}命令，让源节点准备迁出槽的数据。

3）源节点循环执行cluster getkeysinslot{slot}{count}命令，获取count个属于槽{slot}的键。

4）在源节点上执行migrate{targetIp}{targetPort}””0{timeout}keys{keys…} 命令，把获取的键通过流水线（pipeline）机制批量迁移到目标节点，批量迁移版本的migrate命令在Redis3.0.6以上版本提供，之前的migrate命令只能单个键迁移，对于大量key的场景，批量键迁移将极大降低节点之间网络IO次数。

5）重复执行步骤3）和步骤4）直到槽下所有的键值数据迁移到目标节点。

6）向集群内所有主节点发送cluster setslot{slot}node{targetNodeId}命令，通知槽分配给目标节点。为了保证槽节点映射变更及时传播，需要遍历发送给所有主节点更新被迁移的槽指向新节点。

 

（3）添加从节点

扩容之初我们把6385、6386节点加入到集群，节点6385迁移了部分槽和数据作为主节点，但相比其他主节点目前还没有从节点，因此该节点不具备故障转移的能力。

这时需要把节点6386作为6385的从节点，从而保证整个集群的高可用。使用cluster replicate{masterNodeId}命令为主节点添加对应从节点，注意在集群模式下slaveof添加从节点操作不再支持。如下所示：

127.0.0.1:6386>cluster replicate 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756

 

从节点内部除了对主节点发起全量复制之外，还需要更新本地节点的集群相关状态，查看节点6386状态确认已经编程6385节点的从节点。

127.0.0.1:6386>cluster nodes

475528b1bcf8e74d227104a6cf1bf70f00c24aae

127.0.0.1:6386 myself,slave 1a205dd8b2

819a00dd1e8b6be40a8e2abe77b756 0 0 8 connected

1a205dd8b2819a00dd1e8b6be40a8e2abe77b756

127.0.0.1:6385 master – 0 1469779083513 9

connected 0-1365 4096 5462-6826 10923-12287 ..

—————————————

至此，整个集群扩容完成。

 

3、收缩集群

收缩集群意味着缩减规模，需要从现有集群安全下线部分节点。安全下线节点流程如下图所示：

 

流程说明：

1）首先需要确定下线节点是否有负责的槽，如果是，需要把槽迁移到其他节点，保证节点下线后整个集群槽节点映射的完整性。

2）当下线节点不再负责槽或者本身是从节点时，就可以通知集群内其他节点忘记下线节点，当所有的节点忘记该节点后可以正常关闭。

 

1、下线迁移槽

下线节点需要把自己负责的槽迁移到其他节点，原理与之前节点扩容的迁移槽过程一致，收缩正好和扩容迁移方向相反，6381变为源节点，其他主节点变为目标节点，源节点需要把自身负责的4096个槽均匀地迁移到其他主节点上，下线节点槽迁出完成后，剩下的步骤需要让集群忘记该节点。

2、忘记节点

由于集群内的节点不停地通过Gossip消息彼此交换节点状态，因此需要通过一种健壮的机制让集群内所有节点忘记下线的节点。也就是说让其他节点不再与要下线节点进行Gossip消息交换。Redis提供了clusterforget{downNodeId}命令实现该功能。

 

故障转移

Redis集群自身实现了高可用。高可用首先需要解决集群部分失败的场景：当集群内少量节点出现故障时通过自动故障转移保证集群可以正常对外提供服务。下面介绍故障转移的细节，分析故障发现和替换故障节点的过程。

1、故障转移

当集群内某个节点出现问题时，需要通过一种健壮的方式保证识别出节点是否发生了故障。Redis集群内节点通过ping/pong消息实现节点通信，消息不但可以传播节点槽信息，还可以传播其他状态如：主从状态、节点故障等。因此故障发现也是通过消息传播机制实现的，主要环节包括：主观下线（pfail）和客观下线（fail）。

 

1、主观下线：

集群中每个节点都会定期向其他节点发送ping消息，接收节点回复pong消息作为响应。如果在cluster-node-timeout时间内通信一直失败，则发送节点会任务接收节点存在故障，把接收节点标记为主观下线（pfail）状态。流程图如下图所示：

流程说明：

1）节点a发送ping消息给节点b，如果通信正常将接收到pong消息，节点a更新最近一次与节点b的通信时间。

2）如果节点a与节点b通信出现问题则断开连接，下次会进行重连。如果一直通信失败，则节点a记录的与节点b最后通信时间将无法更新。

3）节点a内的定时任务检测到与节点b最后通信时间超过cluster-nodetimeout时，更新本地对节点b的状态为主观下线（pfail）。

主观下线简单来讲就是，当cluster-nodetimeout时间内某节点无法与另一个节点顺利完成ping消息通信时，则将该节点标记为主观下线状态。每个节点内的cluster State结构都需要保存其他节点信息，用于从自身视角判断其他节点的状态。

 

Redis集群对于节点最终是否故障判断非常严谨，只有一个节点任务主观下线并不能判断是否故障。

2、客观下线

当某个节点判断另一个节点主观下线后，相应的节点状态会跟随消息在集群内传播。ping/pong消息的消息体会携带集群1/10的其他节点状态数据，当接受节点发现消息体中含有主观下线的节点状态时，会在本地找到故障节点的ClusterNode结构，保存到下线报告链表中，通过Gossip消息传播，集群内节点不断收集到故障节点的下线报告。当半数以上持有槽的主节点都标记某个节点是主观下线时，触发客观下线流程。

 

2、故障恢复

 

故障节点变为客观下线后，如果下线节点是持有槽的主节点则需要在它的从节点中选出一个替换它，从而保证集群的高可用。下线主节点的所有从节点承担故障恢复的义务，当从节点通过内部定时任务发现自身复制的主节点进入客观下线时，将会触发故障恢复流程。

 

1、资格检查

每个从节点都要检查最后与主节点断线时间，判断是否有资格替换故障的主节点。如果从节点与主节点断线时间超过cluster-node-time*cluster-slave660.validity-factor，则当前从节点不具备故障转移资格。参数cluster-slavevalidity-factor用于从节点的有效因子，默认为10.

 

2、准备选举时间

当从节点符合故障转移资格后，更新触发故障选举的时间，只有到达该时间后才能执行后续流程。这里之所以采用延迟触发机制，主要是通过对多个从节点使用不同的延迟选举时间来支持优先级问题。复制偏移量越大说明从节点延迟越低，那么它应该具有更高的优先级来替换故障主节点。

 

3、发起选举

当从节点定时任务检测到达故障选举时间（failover_auth_time）到达后，发起选举流程如下：

（1）更新配置纪元

配置纪元是一个只增不减的整数，每个主节点自身维护一个配置纪元（clusterNode.configEpoch）标示当前主节点的版本，所有主节点的配置纪元都不相等，从节点会复制主节点的配置纪元。整个集群又维护一个全局的配置纪元（clusterState.currentEpoch），用于记录集群内所有主节点配置纪元的最大版本。

配置纪元会跟随ping/pong消息在集群内传播，当发送方与接收方都是主节点且配置纪元相等时代表出现了冲突，nodeId更大的一方会递增全局配置纪元并赋值给当前节点来区分冲突。

 

配置纪元的主要作用：

• 标示集群内每个主节点的不同版本和当前集群最大的版本。
• 每次集群发生重要时间时，这里的重要时间指出现新的主节点（新加入的或者由从节点转换而来），从节点竞争选举。都会递增集群全局的配置纪元并赋值给相关主节点，用于记录这一关键时间。
• 主节点具有更大的配置纪元代表了更新的集群状态，因此当节点间进行ping/pong消息交换时，如出现slots等关键信息不一致时，以配置纪元更大的一方为准，防止过时的消息状态污染集群。

 

配置纪元的应用场景有：

新节点加入

槽节点映射冲突检测

从节点投票选举冲突检测

 

（2）广播选举消息

在集群内广播选举消息（FAILOVER_AUTH_REQUEST），并记录已发送过消息的状态，保证该从节点在一个配置纪元内只能发起一次选举。消息内容如同ping消息只是将type类型变更为FAILOVER_AUTH_REQUEST。

 

4、选举投票

只有持有槽的主节点才会处理故障选举消息（FAILOVER_AUTH_REQUEST），因为每个持有槽的节点在一个配置纪元都有一个唯一的一张选票，当接到第一个请求投票的从节点消息时回复FAILOVER_AUTH_ACK消息作为投票，之后相同配置纪元内其他从节点的选举消息将忽略。

投票过程其实是一个领导者选举的过程，如集群内有N个持有槽的主节点代表有N涨选票。由于在每个配置纪元内持有槽的主节点只能投票给一个从节点，因此只能有一个从节点获取N/2+1的选票，保证能够找出唯一的从节点。

 

Redis集群没有直接使用从节点进行领导者选举，主要因为从节点数必须大于等于3个才能保证凑够N/2+1个节点，将导致从节点资源浪费。使用集群内所有持有槽的主节点进行领导者选举，即使只有一个从节点也可以完成选举过程。

 

当从节点收集到N/2+1个持有槽的主节点投票时，从节点可以执行替换主节点操作，例如集群内有5个持有槽的主节点，主节点b故障后还有4个，当其中一个从节点收集到3张投票时代表获得了足够的选票可以进行替换主节点操作。

 

5、替换主节点

当从节点收集到足够的选票之后，触发替换主节点操作：

1）当前从节点取消复制变为主节点

2）执行clusterDelSlot操作撤销故障主节点负责的槽，并执行clusterAddSlot把这些槽委派给自己。

3）向集群广播自己的pong消息，通过集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息

 

小结：

1）Redis集群数据分区规则采用虚拟槽方式，所有的键映射到16384个槽中，每个节点负责一部分槽和相关数据，实现数据和请求的负载均衡。

2）集群伸缩通过在节点之间移动槽和相关数据实现。扩容时根据槽迁移计划把源节点迁移到目标节点，源节点负责的槽相比之前变少从而达到集群扩容的目的，收缩时如果下线的节点有负责的槽需要迁移到其他节点，再通过cluster forget命令让集群内其他节点忘记被下线节点。

3）集群自动故障转移过程分为故障发现和故障恢复。节点下线分为主观下线和客观下线，当超过半数主节点认为故障节点为主观下线时标记它为客观下线状态。从节点负责对客观下线的主节点触发故障恢复流程，保证集群的可用性。