Redis - 集群详解

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

一、数据分布

数据分布理论

分布式数据库首先要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整体数据的一个子集。

需要重点关注的是数据分区规则。常见的分区规则有哈希分区和顺序分区两种，由于Redis Cluster采用哈希分区规则，这里我们重点讨论哈希分区，常见的哈希分区规则有几种，下面分别介绍

1.节点取余分区

使用特定的数据，如Redis的键或用户ID，再根据节点数量N使用公式：hash(key) % N 计算出哈希值，用来决定数据映射到哪一个节点上。这种方案存在一个问题：当节点数量变化时，如扩容或收缩节点，数据节点映射关系需要重新计算，会导致数据的重新迁移。

2.一致性哈希分区

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

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

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

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

3.虚拟槽分区

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

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

Redis数据分区

Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0 ~ 16383整数槽内，计算公式：slot=CRC16(key) & 16383。每一个节点负责维护一部分槽以及槽所映射的简直数据，如上图右边部分。

Redis虚拟槽分区的特点：

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

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

集群功能限制

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）准备节点。
2）节点握手。
3）分配槽。

1. 准备节点

Redis集群一般由多个节点组成，节点数量至少为6个才能保证组成完整高可用的集群。每个节点需要开启配置cluster-enable yes，让Redis运行在集群模式下。建议为集群内所有节点同一目录，一般划分三个目录：confi、data、log，分别存放配置、数据和日志相关文件。把6个节点配置同一放在conf目录下，集群相关配置如下：

# 节点端口
port 6379
# 开启集群模式
cluster-enabled yes
# 后台启动
daemonize yes
# 节点超时时间,单位毫秒
cluster-node-timeout 15000
# 集群内部配置文件
cluster-config-file "node-6379.conf"

复制其他五份改掉端口信息即可，启动：

[root@izuf6bsiti3f4kuichki8nz conf]# redis-server redis-6379.conf 
[root@izuf6bsiti3f4kuichki8nz conf]# redis-server redis-6380.conf [root@izuf6bsiti3f4kuichki8nz conf]# redis-server redis-6381.conf 
[root@izuf6bsiti3f4kuichki8nz conf]# redis-server redis-6382.conf 
[root@izuf6bsiti3f4kuichki8nz conf]# redis-server redis-6383.conf 
[root@izuf6bsiti3f4kuichki8nz conf]# redis-server redis-6384.conf 
[root@izuf6bsiti3f4kuichki8nz conf]# ps -ef | grep redis
root      8891     1  0 15:51 ?        00:00:00 redis-server *:6379 [cluster]
root      8914     1  0 15:53 ?        00:00:00 redis-server *:6380 [cluster]
root      8918     1  0 15:53 ?        00:00:00 redis-server *:6381 [cluster]
root      8922     1  0 15:53 ?        00:00:00 redis-server *:6382 [cluster]
root      8927     1  0 15:53 ?        00:00:00 redis-server *:6383 [cluster]
root      8931     1  0 15:54 ?        00:00:00 redis-server *:6384 [cluster]
root      8944  8620  0 15:54 pts/0    00:00:00 grep --color=auto redis
[root@izuf6bsiti3f4kuichki8nz conf]# ll
total 48
-rw-r--r-- 1 root root 112 Sep  8 15:46 node-6379.conf
-rw-r--r-- 1 root root 112 Sep  8 15:53 node-6380.conf
-rw-r--r-- 1 root root 112 Sep  8 15:53 node-6381.conf
-rw-r--r-- 1 root root 112 Sep  8 15:53 node-6382.conf
-rw-r--r-- 1 root root 112 Sep  8 15:54 node-6383.conf
-rw-r--r-- 1 root root 112 Sep  8 15:54 node-6384.conf
-rw-r--r-- 1 root root 220 Sep  8 15:51 redis-6379.conf
-rw-r--r-- 1 root root 220 Sep  8 15:52 redis-6380.conf
-rw-r--r-- 1 root root 220 Sep  8 15:52 redis-6381.conf
-rw-r--r-- 1 root root 220 Sep  8 15:53 redis-6382.conf
-rw-r--r-- 1 root root 220 Sep  8 15:53 redis-6383.conf
-rw-r--r-- 1 root root 220 Sep  8 15:53 redis-6384.conf

node文件为第一次启动自动创建的集群配置文件

第一期启动如果没有集群配置文件，它会自动创建一份，文件名称采用cluster-config-file参数项控制，建议采用node-{port}.conf格式定义，通过使用端口号区分不同节点，防止同一机器下多个不同节点彼此覆盖，造成集群信息异常。如果启动时存在集群配置文件，节点会使用配置文件内容初始化集群信息。启动过程如下：

集群模式的Redis除了原有的配置文件之外又加了一份集群配置文件。当集群内节点信息发生变化，如添加节点、节点下线、故障转移等。节点会自动保存集群状态到配置文件汇总。需要注意的是，Redis自动维护集群配置文件，不要手动修改，防止节点重启时产生集群信息错乱。

现在的每个节点只能识别出自己的节点信息。我们启动6个节点，但每个节点彼此并不知道对方的存在，下面通过节点握手让6个节点彼此建立联系从而组成一个集群。

2. 节点握手

节点握手是指一批运行在集群模式下的节点通过Gossip协议彼此通信，达到感知对方的过程。节点握手是集群彼此通信的第一步，由客户端发起命令：cluster meet {ip} {port}，如下图：

图中执行的命令是：cluster meet 127.0.0.1 6380让节点6379和6380节点进行握手通信。cluster meet命令是一个异步命令，执行之后立刻返回。

分别执行meet命令让其他节点加入到集群中。

[root@izuf6bsiti3f4kuichki8nz conf]# redis-cli -p 6379
127.0.0.1:6379> cluster meet 127.0.0.1 6380
OK
127.0.0.1:6379> cluster meet 127.0.0.1 6381
OK
127.0.0.1:6379> cluster meet 127.0.0.1 6382
OK
127.0.0.1:6379> cluster meet 127.0.0.1 6383
OK
127.0.0.1:6379> cluster meet 127.0.0.1 6384
OK

我们只需要在集群内任一节点上执行cluster meet命令加入新节点，握手状态会通过消息在集群内传播，这样其他节点会自动发现新节点并发起握手流程。最后执行cluster nodes命令确认6个节点都彼此感知并组成集群：

127.0.0.1:6379> cluster nodes
1616aa4bf30563d3163a99d1fb4a89b5cafd6e1c 127.0.0.1:6379 myself,master - 0 0 1 c
onnected
f086a1b4ce424c2bc29da89caee10acb5bdf64bd 127.0.0.1:6383 master - 0 156794959273
7 0 connected
686493a66436bacc60667ea6ee3154191e09a521 127.0.0.1:6380 master - 0 1567949598746 5 connected
14a0a16872ab4d36063ff5616474d6fbd9f27bae 127.0.0.1:6381 master - 0 1567949597744 2 connected
12dcf993d3bff3984371f1a98f4f94bbcf61d689 127.0.0.1:6382 master - 0 1567949594740 3 connected
da6e46db74177c96283de125fddabefd552f7bd5 127.0.0.1:6384 master - 0 1567949596744 4 connected

节点建立握手之后集群还不能正常工作，这是集群处于下线状态，所有的数据读写都被禁止。通过如下命令可以看到：

127.0.0.1:6379> set hello redis
(error) CLUSTERDOWN The cluster is down

通过cluster info可以获取集群当前状态：

127.0.0.1:6379> cluster info
cluster_state:fail
cluster_slots_assigned:0
cluster_slots_ok:0
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:0
cluster_current_epoch:5
cluster_my_epoch:1
cluster_stats_messages_sent:695
cluster_stats_messages_received:695

从输出内容可以看到，被分配的槽（cluster_slots_assigned）是0，由于目前所有的槽没有分配到节点，因此集群无法完成槽到节点的映射。只有当18384个槽全部分配给节点后，集群才进入在线状态。

3.分配槽

Redis集群把所有的数据映射到16384个槽中。每个key会映射为一个固定的槽，只有当节点分配了槽，才能响应和这些槽关联的键命令。通过cluster addslots命令尾节点分配槽。这里利用bash特性批量设置槽（slots），命令如下：

[root@izuf6bsiti3f4kuichki8nz conf]# redis-cli -h 127.0.0.1 -p 6379 cluster add
slots {0..5461}
OK
[root@izuf6bsiti3f4kuichki8nz conf]# redis-cli -h 127.0.0.1 -p 6380 cluster addslots {5462..10922}
OK
[root@izuf6bsiti3f4kuichki8nz conf]# redis-cli -h 127.0.0.1 -p 6381 cluster addslots {10923..16383}
OK

把16383个slot平均分配给6379、6380、6381三个节点。执行cluster info查看集群状态，如下所示：

127.0.0.1:6379> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:5
cluster_my_epoch:1
cluster_stats_messages_sent:7935
cluster_stats_messages_received:7935

当前集群状态是OK，集群进入在线状态。所有的槽都已经分配给节点，执行cluster nodes命令可以看到节点和槽的分配关系：

127.0.0.1:6379> cluster nodes
1616aa4bf30563d3163a99d1fb4a89b5cafd6e1c 127.0.0.1:6379 myself,master - 0 0 1 c
onnected 0-5461
f086a1b4ce424c2bc29da89caee10acb5bdf64bd 127.0.0.1:6383 master - 0 156795340467
0 0 connected
686493a66436bacc60667ea6ee3154191e09a521 127.0.0.1:6380 master - 0 156795340166
6 5 connected 5462-10922
14a0a16872ab4d36063ff5616474d6fbd9f27bae 127.0.0.1:6381 master - 0 156795340066
5 2 connected 10923-16383
12dcf993d3bff3984371f1a98f4f94bbcf61d689 127.0.0.1:6382 master - 0 1567953403669 3 connected
da6e46db74177c96283de125fddabefd552f7bd5 127.0.0.1:6384 master - 0 1567953402668 4 connected

目前还有三个节点没有使用，作为一个完整的集群，每个负责处理槽的节点应该具有从节点，保证当它出现故障时可以自动进行故障转移。集群模式下，Redis节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。使用cluster replicate {nodeId}命令让一个节点成为从节点。其中命令执行必须在对应的从节点上执行，nodeId是要复制主节点的节点ID，如下：

[root@izuf6bsiti3f4kuichki8nz conf]# redis-cli -p 6382
127.0.0.1:6382> cluster replicate 1616aa4bf30563d3163a99d1fb4a89b5cafd6e1c
OK
127.0.0.1:6382> exit
[root@izuf6bsiti3f4kuichki8nz conf]# redis-cli -p 6383
127.0.0.1:6383> cluster replicate 686493a66436bacc60667ea6ee3154191e09a521
OK
127.0.0.1:6383> exit
[root@izuf6bsiti3f4kuichki8nz conf]# redis-cli -p 6384
127.0.0.1:6384> cluster replicate 14a0a16872ab4d36063ff5616474d6fbd9f27bae
OK

通过cluster nodes命令查看集群状态和复制状态：

127.0.0.1:6379> cluster nodes
1616aa4bf30563d3163a99d1fb4a89b5cafd6e1c 127.0.0.1:6379 myself,master - 0 0 1 connected 0-5461
f086a1b4ce424c2bc29da89caee10acb5bdf64bd 127.0.0.1:6383 slave 686493a66436bacc60667ea6ee3154191e09a521 0 1567953844433 5 connected
686493a66436bacc60667ea6ee3154191e09a521 127.0.0.1:6380 master - 0 1567953842423 5 connected 5462-10922
14a0a16872ab4d36063ff5616474d6fbd9f27bae 127.0.0.1:6381 master - 0 1567953845435 2 connected 10923-16383
12dcf993d3bff3984371f1a98f4f94bbcf61d689 127.0.0.1:6382 slave 1616aa4bf30563d3163a99d1fb4a89b5cafd6e1c 0 1567953846436 3 connected
da6e46db74177c96283de125fddabefd552f7bd5 127.0.0.1:6384 slave 14a0a16872ab4d36063ff5616474d6fbd9f27bae 0 1567953847438 4 connected

目前为止，我们依照Redis协议手动建立一个集群。它由6个节点构成，3个主节点负责处理槽和相关数据，3个从节点负责故障转移。手动搭建集群便于理解集群建立的流程和细节，不过当集群节点众多时，必然会加大搭建集群的复杂度和运维成本。因此Redis官方提供了redis-trib.rb工具方便我们快速搭建集群。

redis-trib.rb是采用Ruby实现的Redis集群管理工具。内部通过Cluster相关命令帮我们简化集群创建、检查、槽迁移和均衡等常见运维操作，使用前需要安装Ruby依赖环境。这里我们简单介绍下流程

1. Ruby环境准备
2. 准备节点
3. 创建集群：使用 redis-trib.rb create 命令完成节点握手和槽分配过程。
4. 集群完整性检查

三、节点通信

四、集群伸缩

五、请求路由

六、故障转移

七、集群运维

重点回顾

1）Redis集群数据分区规则采用虚拟槽方式，所有的键映射到16384个槽中，每个节点负责一部分槽和相关数据，实现数据和请求的负载均衡。
2）搭建集群划分三个步骤：准备节点，节点握手，分配槽。可以使用 redis-trib.rb create 命令快速搭建集群。
3）集群内部节点通信采用Gossip协议彼此发送消息，消息类型分为：ping消息、pong消息、meet消息、fail消息等。节点定期不断发送和接受ping/pong消息来维护更新集群的状态。消息内容包括节点自身数据和部分其他节点的状态数据。
4）集群伸缩通过在节点之间移动槽和相关数据实现。扩容时根据槽迁移计划把槽从源节点迁移到目标节点，源节点负责的槽相比之前变少从而达到集群扩容的目的，收缩时如果下线的节点有负责的槽需要迁移到其他节点，再通过cluster forget命令让集群内其他节点忘记被下线节点。
5）使用Smart客户端操作集群达到通信效率最大化，客户端内部负责计算维护键 ——> 节点的映射，用于快速定位键命令到目标节点。集群协议通过Smart客户端全面高效的支持需要一个过程，用户在选择Smart客户端时建议review下集群交互代码如：异常判定和重试逻辑，更新槽的并发控制等。节点接收到键命令时会判断相关的槽是否由自身节点负责，如果不是则返回重定向信息。重定向分为MOVED和ASK，ASK说明集群正在进行槽数据迁移，客户端只在本次请求中做临时重定向，不会更新本地槽缓存。MOVED重定向说明槽已经明确分配到另一个节点，客户端需要更新槽节点缓存。
6）集群自动故障转移过程分为故障发现和故障恢复。节点下线分为主观下线和客观下线，当超过半数主节点认为故障节点为主观下线时标记它为客观下线状态。从节点负责对客观下线的主节点触发故障恢复流程，保证集群的可用性。
7）开发和运维集群过程中常见问题包括：超大规模集群带宽消耗，pub/sub 广播问题，集群节点倾斜问题，手动故障转移，在线迁移数据等。