Redis集合，Redis Cluster是Redis的分布式解决方案，当遇到单机内存、并发、流量等瓶颈时，可以采用Cluster架构方案达到负载均衡的目的

目录

一、数据分布

1.数据分布理论

2.Redis数据分区

3.集群功能限制

二、搭建集群

1.准备节点

2.节点握手

3.分配槽

4.用redis-trib.rb搭建集群

三、节点通信

1.通信流程

2.Gossip消息

3.节点选择

四、集群伸缩

1.伸缩原理

2.扩容集群

3.收缩集群

五、请求路由

1.请求重定向

2.Smart客户端

3.ASK重定向

六、故障转移

1.故障发现

2.故障恢复

3.故障转移时间

4.故障转移演练

本章重点回顾

文章将从数据分布、搭建集群、节点通信、集群伸缩、请求路由、 故障转移、集群运维几个方面介绍Redis Cluster。

一、数据分布

1.数据分布理论

把数据集按照分区规则划分到多个节点上，每个节点负责整体数据的一 个子集；

常见的分区规则有哈希分区和顺 序分区两种，Redis Cluster采用哈希分区规则；

常见的哈希分区规则有几种：

1.节点取余分区

使用特定的数据，如Redis的键或用户ID，再根据节点数量N使用公 式：hash（key）%N计算出哈希值，用来决定数据映射到哪一个节点 上。

缺点：当节点数量变化时，如扩容或收缩节点， 数据节点映射关系需要重新计算，会导致数据的重新迁移

优点：简单性，常用于数据库的分库分表规则，一般采用预分区的方式，提前根据数据量规划好分区数，再根据负载情况将表 迁移到其他数据库中。扩容时通常采用翻倍扩容，避免数据映射全部被 打乱导致全量迁移的情况

2.一致性哈希分区

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

优点：加入和删除节点只影响哈希 环中相邻的节点，对其他节点无影响

缺点：

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

3.虚拟槽分区

虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把 所有数据映射到一个固定范围的整数集合中，整数定义为槽（slot）；Redis Cluster槽范围是0~16383；

槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是为了 方便数据拆分和集群扩展。每个节点会负责一定数量的槽；当前集群有5个节点，每个节点平均大约负责3276个槽。

2.Redis数据分区

Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到 0~16383整数槽内，计算公式：slot=CRC16（key）&16383。每一个节 点负责维护一部分槽以及槽所映射的键值数据；

Redis虚拟槽分区的特点：

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

3.集群功能限制

Redis集群相对单机在功能上存在的一些限制：

1）key批量操作支持有限，如mset、mget，目前只支持具有相同 slot值的key执行批量操作。

2）key事务操作支持有限。同理只支持多key在同一节点上的事务操作

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

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

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

二、搭建集群

搭建集群工作需要以下三个步骤：

1）准备节点

2）节点握手

3）分配槽

1.准备节点

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

把6个节 点配置统一放在conf目录下，集群相关配置如下：

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

其他配置和单机模式一致即可，配置文件命名规则redis- {port}.conf，准备好配置后启动所有节点：

redis-server conf/redis-6379.confredis-server conf/redis-6380.confredis-server conf/redis-6381.confredis-server conf/redis-6382.confredis-server conf/redis-6383.confredis-server conf/redis-6384.conf

检查节点日志是否正确，日志内容如下：

cat log/redis-6379.log* No cluster configuration found, I'm cfb28ef1deee4e0fa78da86abe5d24566744411e# Server started, Redis version 3.0.7* The server is now ready to accept connections on port 6379

集群模式的Redis除了原有的配置文件之外Redis还自动维护了一个集群配置文件，集群内节点信息发生变化时，节点会自动保存集群状态到配置文件中不需要手动修改，可以防止节点重启时产生集群信息错乱。

6379首次启动后生成集群配置：

#cat data/nodes-6379.confcfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connectedvars currentEpoch 0 lastVoteEpoch 0#文件内容记录了集群初始状态，这里最重要的是节点ID，它是一个40位16进制字符串，用于唯一标识集群内一个节点#在节点6380执行cluster nodes命令获取集群节点状态：127.0.0.1:6380>cluster nodes8e41673d59c9568aa9d29fb174ce733345b3e8f1 127.0.0.1:6380 myself,master - 0 0 0 connected

2.节点握手

节点握手让6个节点彼此 建立联系从而组成一个集群，节点握手是指一批运行在集群模式下的节点通过Gossip协议彼此通 信，达到感知对方的过程。节点握手是集群彼此通信的第一步，由客户 端发起命令：cluster meet{ip}{port}；

cluster meet命令是一个异步命令，执行之后立刻返 回。内部发起与目标节点进行握手通信：

1）节点6379本地创建6380节点信息对象，并发送meet消息

2）节点6380接受到meet消息后，保存6379节点信息并回复pong消息

3）之后节点6379和6380彼此定期通过ping/pong消息进行正常的节点通信

#在客户端查看集群状态只能看到与之建立通信连接的节点127.0.0.1:6379> cluster nodescfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 00 connected8e41673d59c9568aa9d29fb174ce733345b3e8f1 127.0.0.1:6380 master - 0 14680735342651 connected127.0.0.1:6380> cluster nodescfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 master - 0 14680735716410 connected8e41673d59c9568aa9d29fb174ce733345b3e8f1 127.0.0.1:6380 myself,master - 0 01 connected

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

节点建立握手之后集群还不能正常工作，这时集群处于下线状态， 所有的数据读写都被禁止；通过cluster info命令可以获取集群当前状态：

127.0.0.1:6379> cluster infocluster_state:failcluster_slots_assigned:0cluster_slots_ok:0cluster_slots_pfail:0cluster_slots_fail:0cluster_known_nodes:6cluster_size:0

cluster_slots_assigned：0 被分配的槽是0；目前所有的槽没有分配到节点，因此集群无法完成槽到节点的映 射。只有当16384个槽全部分配给节点后，集群才进入在线状态。

3.分配槽

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

redis-cli -h 127.0.0.1 -p 6379 cluster addslots {0...5461}redis-cli -h 127.0.0.1 -p 6380 cluster addslots {5462...10922}redis-cli -h 127.0.0.1 -p 6381 cluster addslots {10923...16383}#把16384个slot平均分配给6379、6380、6381三个节点。执行clusterinfo查看集群状态127.0.0.1:6379> cluster infocluster_state:okcluster_slots_assigned:16384cluster_slots_ok:16384cluster_slots_pfail:0cluster_slots_fail:0cluster_known_nodes:6cluster_size:3cluster_current_epoch:5cluster_my_epoch:0cluster_stats_messages_sent:4874cluster_stats_messages_received:4726#当前集群状态是OK，集群进入在线状态。所有的槽都已经分配给节点，执行cluster nodes命令可以看到节点和槽的分配关系：127.0.0.1:6379> cluster nodes4fa7eac4080f0b667ffeab9b87841da49b84a6e4 127.0.0.1:6384 master - 0 14680762401235 connectedcfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connected0-5461be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 master - 0 14680762396224 connected40622f9e7adc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 master - 0 14680762406283 connected8e41673d59c9568aa9d29fb174ce733345b3e8f1 127.0.0.1:6380 master - 0 14680762376061 connected5462-1092240b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 master - 0 14680762386122 connected10923-16383

目前还有三个节点没有使用，作为一个完整的集群，每个负责处理 槽的节点应该具有从节点，保证当它出现故障时可以自动进行故障转移。

集群模式下，Reids节点角色分为主节点和从节点。首次启动的节 点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。

使用cluster replicate{nodeId}命令让一个节点成为从节点（给主节点分配从节点）。其中命令执行必须在对应的从节点上执行，nodeId是要复制主节点的节点 ID，命令如下：

127.0.0.1:6382>cluster replicate cfb28ef1deee4e0fa78da86abe5d24566744411eOK127.0.0.1:6383>cluster replicate 8e41673d59c9568aa9d29fb174ce733345b3e8f1OK127.0.0.1:6384>cluster replicate 40b8d09d44294d2e23c7c768efc8fcd153446746OK

集群完整结构：

4.用redis-trib.rb搭建集群

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

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

1.Ruby环境准备

安装Ruby：-- 下载rubywget https:// cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.gz-- 安装rubytar xvf ruby-2.3.1.tar.gz./configure -prefix=/usr/local/rubymakemake installcd /usr/local/rubysudo cp bin/ruby /usr/local/binsudo cp bin/gem /usr/local/bin

安装rubygem redis依赖：wget http:// rubygems.org/downloads/redis-3.3.0.gemgem install -l redis-3.3.0.gemgem list --check redis gem

安装redis-trib.rb：sudo cp /{redis_home}/src/redis-trib.rb /usr/local/bin

安装完Ruby环境后，执行redis-trib.rb命令确认环境是否正确，输出如下：# redis-trib.rbUsage: redis-trib   create host1:port1 ... hostN:portN--replicas check host:portinfo host:portfix host:port--timeout reshard host:port--from --to --slots --yes--timeout --pipeline 

redis-trib.rb提供了集群创建、检查、修 复、均衡等命令行工具。我们关注集群创建命令，使用redis-trib.rb create命令可快速搭建集群；

2.准备节点

准备好节点配置并启动

redis-server conf/redis-6481.confredis-server conf/redis-6482.confredis-server conf/redis-6483.confredis-server conf/redis-6484.confredis-server conf/redis-6485.confredis-server conf/redis-6486.conf

3.创建集群

1）使用redis-trib.rb create命令完成节点握手和槽 分配过程

redis-trib.rb create --replicas 1 127.0.0.1:6481 127.0.0.1:6482 127.0.0.1:6483127.0.0.1:6484 127.0.0.1:6485 127.0.0.1:6486

–replicas参数指定集群中每个主节点配备几个从节点

–如果部署节点使用不同的IP地址，redis-trib.rb会尽可能保证主从节点不分配在同一机器下

2）创建过程中首先会给出主从节点角色分配的计划：

>>> Creating cluster>>> Performing hash slots allocation on 6 nodes...Using 3 masters:127.0.0.1:6481127.0.0.1:6482127.0.0.1:6483Adding replica 127.0.0.1:6484 to 127.0.0.1:6481Adding replica 127.0.0.1:6485 to 127.0.0.1:6482Adding replica 127.0.0.1:6486 to 127.0.0.1:6483M: 869de192169c4607bb886944588bc358d6045afa 127.0.0.1:6481slots:0-5460 (5461 slots) masterM: 6f9f24923eb37f1e4dce1c88430f6fc23ad4a47b 127.0.0.1:6482slots:5461-10922 (5462 slots) masterM: 6228a1adb6c26139b0adbe81828f43a4ec196271 127.0.0.1:6483slots:10923-16383 (5461 slots) masterS: 22451ea81fac73fe7a91cf051cd50b2bf308c3f3 127.0.0.1:6484replicates 869de192169c4607bb886944588bc358d6045afaS: 89158df8e62958848134d632e75d1a8d2518f07b 127.0.0.1:6485replicates 6f9f24923eb37f1e4dce1c88430f6fc23ad4a47bS: bcb394c48d50941f235cd6988a40e469530137af 127.0.0.1:6486replicates 6228a1adb6c26139b0adbe81828f43a4ec196271Can I set the above configuration (type 'yes' to accept):

3）输入yes，redis-trib.rb开始执行节点握手和 槽分配操作：

>>> Nodes configuration updated>>> Assign a different config epoch to each node>>> Sending CLUSTER MEET messages to join the clusterWaiting for the cluster to join..>>> Performing Cluster Check (using node 127.0.0.1:6481)...忽略...[OK] All nodes agree about slots configuration.>>> Check for open slots...>>> Check slots coverage...[OK] All 16384 slots covered.#最后的输出报告说明：16384个槽全部被分配，集群创建成功。这里需要注意给redis-trib.rb的节点地址必须是不包含任何槽/数据的节点，否则会拒绝创建集群

4.集群完整性检查

集群完整性指所有的槽都分配到存活的主节点上，只要16384个槽 中有一个没有分配给节点则表示集群不完整。

使用redis-trib.rb check命令检测之前创建的两个集群是否成功（只需要给出集 群中任意一个节点地址）：

redis-trib.rb check 127.0.0.1:6379#输出信息，提示集群所有的槽都已分配到节点[OK] All 16384 slots covered.

三、节点通信

1.通信流程

Redis集群采用P2P的Gossip（流言） 协议，在分布式存储中提供维护节点元数据信息的机制，所谓元数据 是指节点负责哪些数据，是否出现故障等状态信息。Gossip协议工作原理就是节点彼此不断通信交换信息，一段时间 后所有的节点都会知道集群完整的信息；

通信过程：

1）集群中的每个节点都会单独开辟一个TCP通道，用于节点之间 彼此通信，通信端口号在基础端口上加10000

2）每个节点在固定周期内通过特定规则选择几个节点发送ping消息

3）接收到ping消息的节点用pong消息作为响应

集群中每个节点通过一定规则挑选要通信的节点，每个节点可能知 道全部节点，也可能仅知道部分节点，只要这些节点彼此可以正常通 信，最终它们会达到一致的状态，从而 达到集群状态同步的目的；

2.Gossip消息

Gossip协议的主要职责就是信息交换。信息交换的载体就是节点彼 此发送的Gossip消息；

常用的Gossip消息可分为：ping消息、pong消息、meet消息、fail消 息等:

• ·meet消息：用于通知新节点加入。消息发送者通知接收者加入到 当前集群,通信正常完成后，接收节点会加入到集群中并进行 周期性的ping、pong消息交换
• ·ping消息：集群内交换最频繁的消息，集群内每个节点每秒向多个 其他节点发送ping消息，用于检测节点是否在线和交换彼此状态信息(封装了自身节点和部分其他节点的状态数据)
• ·pong消息：当接收到ping、meet消息时，作为响应消息回复给发送 方确认消息正常通信(封装了自身状态数据)，节点也可以 向集群内广播自身的pong消息来通知整个集群对自身状态进行更新；
• ·fail消息：当节点判定集群内另一个节点下线时，会向集群内广播 一个fail消息

消息格式划分为：消息头和消息体。消息头包含发送节点自 身状态数据，接收节点根据消息头就可以获取到发送节点的相关数据

#集群内所有的消息都采用相同的消息头结构clusterMsg，它包含了发送节点关键信息，如节点id、槽映射、节点标识（主从角色，是否下线）等typedef struct {char sig[4]; /* 信号标示*/uint32_t totlen; /* 消息总长度*/uint16_t ver; /* 协议版本*/uint16_t type; /* 消息类型,用于区分meet,ping,pong等消息*/uint16_t count; /* 消息体包含的节点数量，仅用于meet,ping,ping消息类型*/uint64_t currentEpoch; /* 当前发送节点的配置纪元*/uint64_t configEpoch; /* 主节点/从节点的主节点配置纪元*/uint64_t offset; /* 复制偏移量*/char sender[CLUSTER_NAMELEN]; /* 发送节点的nodeId */unsigned char myslots[CLUSTER_SLOTS/8]; /* 发送节点负责的槽信息*/char slaveof[CLUSTER_NAMELEN]; /* 如果发送节点是从节点，记录对应主节点的nodeId */uint16_t port; /* 端口号*/uint16_t flags; /* 发送节点标识,区分主从角色，是否下线等*/unsigned char state; /* 发送节点所处的集群状态*/unsigned char mflags[3]; /* 消息标识*/union clusterMsgData data /* 消息正文*/;} clusterMsg;

#消息体clusterMsgData定义发送消息的数据，其中ping、meet、pong都采用cluster MsgDataGossip数组作为消息体数据，实际消息类型使用消息头的type属性区分。每个消息体包含该节点的多个clusterMsgDataGossip结构数据，用于信息交换union clusterMsgData {/* ping,meet,pong消息体*/struct {/* gossip消息结构数组*/clusterMsgDataGossip gossip[1];} ping;/* FAIL 消息体*/struct {clusterMsgDataFail about;} fail;// ...};

#clusterMsgDataGossip结构数据，用于信息交换typedef struct {char nodename[CLUSTER_NAMELEN]; /* 节点的nodeId */uint32_t ping_sent; /* 最后一次向该节点发送ping消息时间*/uint32_t pong_received; /* 最后一次接收该节点pong消息时间*/char ip[NET_IP_STR_LEN]; /* IP */uint16_t port; /* port*/uint16_t flags; /* 该节点标识, */} clusterMsgDataGossip;

当接收到ping、meet消息时，接收节点会解析消息内容并根据自身的识别情况做出相应处理，流程如下：

1）解析消息头过程：消息头包含了发送节点的信息，如果发送节点 是新节点且消息是meet类型，则加入到本地节点列表；如果是已知节 点，则尝试更新发送节点的状态，如槽映射关系、主从角色等状态

2）解析消息体过程：如果消息体的clusterMsgDataGossip数组包含的节点是新节点，则尝试发起与新节点的meet握手流程；如果是已知节点，则根据cluster MsgDataGossip中的flags字段判断该节点是否下线，用于故障转移

消息处理完后回复pong消息，内容同样包含消息头和消息体，发送 节点接收到回复的pong消息后，采用类似的流程解析处理消息并更新与 接收节点最后通信时间，完成一次消息通信。

3.节点选择

Redis集群内节点通信采用固定频率（定时任务每秒执行10次）。因此节点每次选择需要通信的节点列表变得非常重要。通信节点选择过 多虽然可以做到信息及时交换但成本过高。节点选择过少会降低集群内 所有节点彼此信息交换频率，从而影响故障判定、新节点发现等需求的速度。

Gossip协议通信节点选择的规则：

兼顾信息交换实时性和成本开销

消息交换的成本主要体现在单位 时间选择发送消息的节点数量和每个消息携带的数据量；

1）选择发送消息的节点数量

集群内每个节点维护定时任务默认每秒执行10次，每秒会随机选取 5个节点找出最久没有通信的节点发送ping消息，用于保证Gossip信息交 换的随机性。

每100毫秒都会扫描本地节点列表，如果发现节点最近一 次接受pong消息的时间大于cluster_node_timeout/2，则立刻发送ping消 息，防止该节点信息太长时间未更新。根据以上规则得出每个节点每秒 需要发送ping消息的数量 =1+10*num（node.pong_received>cluster_node_timeout/2），因此 cluster_node_timeout参数对消息发送的节点数量影响非常大。当我们的 带宽资源紧张时，可以适当调大这个参数，如从默认15秒改为30秒来降 低带宽占用率。

过度调大cluster_node_timeout会影响消息交换的频率从 而影响故障转移、槽信息更新、新节点发现的速度。

2）消息数据量

每个ping消息的数据量体现在消息头和消息体中，其中消息头主要 占用空间的字段是myslots[CLUSTER_SLOTS/8]，占用2KB，这块空间 占用相对固定。消息体会携带一定数量的其他节点信息用于信息交换；

消息体携带数据量跟集群的节点数息息相关， 更大的集群每次消息通信的成本也就更高，对于Redis集群来说并 不是大而全的集群更好；

四、集群伸缩

Redis集群提供了灵活的节点扩容和收缩方案，集群可以添加节点进行扩容也可以下线部分节点进行缩容；它是Redis集群化之后最重要的功能，熟练掌握集群伸缩可以应对线上数据规模和并发量；

1.伸缩原理

Redis集群可以实现对节点的灵活上下线控制。其 中原理可抽象为槽和对应数据在不同节点之间灵活移动；

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

每个节点把一部分槽和数据迁移到新的节点6385，每个节点负 责的槽和数据相比之前变少了从而达到了集群扩容的目的；集群伸缩= 槽和数据在节点之间的移动；

2.扩容集群

1）准备新节点

准备好新节点并运行在集群模式下，新节点建议跟集群内 的节点配置保持一致，此时新节点并没有与集群建立通信所以此时新节点属于孤儿节点；

2）加入集群

新节点依然采用cluster meet命令加入到现有集群中，从孤儿节点加入到集群通信中；集群内新旧节点经过一段时间的ping/pong消息通信之后，所有节点 会发现新节点并将它们的状态保存到本地。

新节点刚开始都是主节点状态，但是由于没有负责的槽，所以不能接受任何读写操作。一般会有两种操作一是为它迁移槽和数据实现扩容，二是作为其他主节点的从节点负责故障转移。

通过redis-trib.rb工具为现有集群添加新节点的命令

直接添加为从节点：

redis-trib.rb add-node new_host:new_port existing_host:existing_port --slave--master-id 

建议使用redis-trib.rb add-node命令加入新节点，该命令内 部会执行新节点状态检查，如果新节点已经加入其他集群或者包含数 据，则放弃集群加入操作并打印如下信息

redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379redis-trib.rb add-node 127.0.0.1:6386 127.0.0.1:6379

如果我们手动执行cluster meet命令加入已经存在于其他集群的节 点，会造成被加入节点的集群合并到现有集群的情况，从而造成数据丢 失和错乱，后果非常严重，线上谨慎操作。

3）迁移槽和数据

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

（1）槽迁移计划

槽是Redis集群管理数据的基本单位，首先需要为新节点制定槽的 迁移计划，确定原有节点的哪些槽需要迁移到新节点。迁移计划需要确 保每个节点负责相似数量的槽，从而保证各节点的数据均匀；

（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} 命令，通知槽分配给目标节点。为了保证槽节点映射变更及时传播，需 要遍历发送给所有主节点更新被迁移的槽指向新节点；

使用命令把源节点6379负责的槽4096迁移到目标节点6385中，整体流程如下：

1）目标节点准备导入槽4096数据：127.0.0.1:6385>cluster setslot 4096 importing cfb28ef1deee4e0fa78da86abe5d24566744411eOK确认槽4096导入状态开启：127.0.0.1:6385>cluster nodes1a205dd8b2819a00dd1e8b6be40a8e2abe77b756 127.0.0.1:6385 myself,master - 0 0 7 connected[4096-cluster setslot 4096 migrating 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756OK确认槽4096导出状态开启：127.0.0.1:6379>cluster nodescfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connected0-5461 [4096->-1a205dd8b2819a00dd1e8b6be40a8e2abe77b756]...3）批量获取槽4096对应的键，这里我们获取到3个处于该槽的键：127.0.0.1:6379> cluster getkeysinslot 4096 1001) "key:test:5028"2) "key:test:68253"3) "key:test:79212"确认这三个键是否存在于源节点：127.0.0.1:6379>mget key:test:5028 key:test:68253 key:test:792121) "value:5028"2) "value:68253"3) "value:79212"4）批量迁移这3个键，migrate命令保证了每个键迁移过程的原子性：127.0.0.1:6379>migrate 127.0.0.1 6385 "" 0 5000 keys key:test:5028 key:test:68253key:test:79212查询这三个键，发现已经不在源节点中，Redis返回ASK转向错误127.0.0.1:6379> mget key:test:5028 key:test:68253 key:test:79212(error) ASK 4096 127.0.0.1:63855）通知所有主节点槽4096指派给目标节点6385：127.0.0.1:6379>cluster setslot 4096 node 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756127.0.0.1:6380>cluster setslot 4096 node 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756127.0.0.1:6381>cluster setslot 4096 node 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756127.0.0.1:6385>cluster setslot 4096 node 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756确认源节点6379不再负责槽4096改为目标节点6385负责：127.0.0.1:6379> cluster nodescfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connected0-4095 4097-54611a205dd8b2819a00dd1e8b6be40a8e2abe77b756 127.0.0.1:6385 master - 0 1469718011079 7connected 4096

实际操作时肯定涉及大量槽并且每个槽对应非常多的键所以我们不能通过命令来进行迁移数据操作。因此 redis-trib提供了槽重分片功能：

redis-trib.rb reshard host:port --from--to--slots--yes --timeout --pipeline 

• ·host：port：必传参数，集群内任意节点地址，用来获取整个集群 信息。
• ·–from：制定源节点的id，如果有多个源节点，使用逗号分隔，如 果是all源节点变为集群内所有主节点，在迁移过程中提示用户输入。
• ·–to：需要迁移的目标节点的id，目标节点只能填写一个，在迁移 过程中提示用户输入。
• ·–slots：需要迁移槽的总数量，在迁移过程中提示用户输入。
• ·–yes：当打印出reshard执行计划时，是否需要用户输入yes确认后 再执行reshard。
• ·–timeout：控制每次migrate操作的超时时间，默认为60000毫秒。
• ·–pipeline：控制每次批量迁移键的数量，默认为10。

#1）输入命令redis-trib.rb reshard 127.0.0.1:6379#2）打印出集群每个节点信息后，reshard命令需要确认迁移的槽数量，我们输入4096个：How many slots do you want to move (from 1 to 16384)4096#3）输入6385的节点ID作为目标节点，目标节点只能指定一个：What is the receiving node ID 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756#4）之后输入源节点的ID，这里分别输入节点6379、6380、6381三个节点ID最后用done表示结束：Please enter all the source node IDs.Type 'all' to use all the nodes as source nodes for the hash slots.Type 'done' once you entered all the source nodes IDs.Source node #1:cfb28ef1deee4e0fa78da86abe5d24566744411eSource node #2:8e41673d59c9568aa9d29fb174ce733345b3e8f1Source node #3:40b8d09d44294d2e23c7c768efc8fcd153446746Source node #4:done#5）数据迁移之前会打印出所有的槽从源节点到目标节点的计划，确认计划无误后输入yes执行迁移工作：Moving slot 0 from cfb28ef1deee4e0fa78da86abe5d24566744411e....Moving slot 1365 from cfb28ef1deee4e0fa78da86abe5d24566744411eMoving slot 5462 from 8e41673d59c9568aa9d29fb174ce733345b3e8f1...Moving slot 6826 from 8e41673d59c9568aa9d29fb174ce733345b3e8f1Moving slot 10923 from 40b8d09d44294d2e23c7c768efc8fcd153446746...Moving slot 12287 from 40b8d09d44294d2e23c7c768efc8fcd153446746Do you want to proceed with the proposed reshard plan (yes/no) yes#6）当所有的槽迁移完成后，reshard命令自动退出，执行cluster nodes命令检查节点和槽映射的变化：127.0.0.1:6379>cluster nodes#7）迁移之后建议使用redis-trib.rb rebalance命令检查节点之间槽的均衡性。命令如下：# redis-trib.rb rebalance 127.0.0.1:6380

（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

到此整个集群扩容完成：

3.收缩集群

收缩集群，从现有集群中安全下线部分节点，流程如下：

1.下线迁移槽

下线节点需要把自己负责的槽迁移到其他节点，原理与之前节点扩容的迁移槽过程一致；

#6381是主节点，负责槽（12288-16383），6384是它的从节点127.0.0.1:6381> cluster nodes40b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 myself,master - 0 0 2 connected12288-163834fa7eac4080f0b667ffeab9b87841da49b84a6e4 127.0.0.1:6384 slave 40b8d09d44294d2e23c7c768efc8fcd153446746 0 1469894180780 5 connected

收缩正好和扩容迁移方向相反，6381变为源节点，其他主节点变为目标节点，源节点需要把自身负责的4096个槽均匀地迁移到其他主节点上。这里直接使用redis-trib.rb reshard命令完成槽迁移。由于每次执行 reshard命令只能有一个目标节点，因此需要执行3次reshard命令，分别迁移1365、1365、1366个槽；

#redis-trib.rb reshard 127.0.0.1:6381>>> Performing Cluster Check (using node 127.0.0.1:6381)...[OK] All 16384 slots covered.How many slots do you want to move (from 1 to 16384)1365What is the receiving node ID cfb28ef1deee4e0fa78da86abe5d24566744411e /*输入6379节点id作为目标节点.*/Please enter all the source node IDs.Type 'all' to use all the nodes as source nodes for the hash slots.Type 'done' once you entered all the source nodes IDs.Source node #1:40b8d09d44294d2e23c7c768efc8fcd153446746 /*源节点6381 id*/Source node #2:done /* 输入done确认*/...Do you want to proceed with the proposed reshard plan (yes/no) yes...槽迁移完成后，6379节点接管了1365个槽12288~13652，如下所示：127.0.0.1:6379> cluster nodescfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 10 connected1366-4095 4097-5461 12288-1365240b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 master - 0 1469895725227 2connected 13653-16383...

继续把1365个槽迁移到节点6380，把最后的1366个槽迁移到节点6385中，节点6381所有的槽全部迁出完成，6381不再负责任何槽；

2.忘记节点

集群内的节点不停地通过Gossip消息彼此交换节点状态，Redis提供了cluster forget{downNodeId}命令实现让其他节点不再与要下线节点进行Gossip消息交换；

当节点接收到cluster forget{down NodeId}命令后，会把nodeId指定 的节点加入到禁用列表中，在禁用列表内的节点不再发送Gossip消息。 禁用列表有效期是60秒，超过60秒节点会再次参与消息交换。也就是说 当第一次forget命令发出后，我们有60秒的时间让集群内的所有节点忘 记下线节点。 线上操作不建议直接使用cluster forget命令下线节点，需要跟大量 节点命令交互，实际操作起来过于繁琐并且容易遗漏forget节点。

使用redis-trib.rb del-node{host：port}{downNodeId}命令：

#del-node命令帮我们实现了安全下线的后续操作。当下线主节点具有从节点时需要把该从节点指向到其他主节点，因此对于主从节点都下线的情况，建议先下线从节点再下线主节点，防止不必要的全量复制redis-trib.rb del-node 127.0.0.1:6379 4fa7eac4080f0b667ffeab9b87841da49b84a6e4 #从节点 6384 idredis-trib.rb del-node 127.0.0.1:6379 40b8d09d44294d2e23c7c768efc8fcd153446746 #主节点 6381 id#节点下线后确认节点状态：127.0.0.1:6379> cluster nodes

五、请求路由

使用客户端去操作集群，Redis集群对客户端通信协议做了比较大的修改，为了追求性能最大化，并没有采用代理的方式而是采用客户端直连节点的方式。因此对于从单机切换到集群环境的应用需要修改客户端代码；

1.请求重定向

Redis在集群模式下接收任何键相关命令时首先计算键对应的槽，再根据槽找出所对应的节点，如果节点是自身，则处理键命令；否则回复MOVED重定向错误，通知客户端请求正确的节点，这个过程称为MOVED重定向。

#cluster keyslot{key}命令返回key所对应的槽：127.0.0.1:6379> cluster keyslot key:test:1(integer) 5191127.0.0.1:6379> cluster nodescfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 10 connected1366-4095 4097-5461 12288-13652

#键对应槽是9252，不属于6379节点，则回复MOVED{slot}{ip}{port}格式重定向信息：127.0.0.1:6379> set key:test:2 value-2(error) MOVED 9252 127.0.0.1:6380127.0.0.1:6379> cluster keyslot key:test:2(integer) 9252

重定向信息包含了键所对应的槽以及负责该槽的节点地址，根据这 些信息客户端就可以向正确的节点发起请求。在6380节点上成功执行之 前的命令：

127.0.0.1:6380> set key:test:2 value-2OK

使用redis-cli命令时，可以加入-c参数支持自动重定向，简化手动发 起重定向操作

#redis-cli -p 6379 -c127.0.0.1:6379> set key:test:2 value-2-> Redirected to slot [9252] located at 127.0.0.1:6380OK

redis-cli自动帮我们连接到正确的节点执行命令，这个过程是在 redis-cli内部维护，实质上是client端接到MOVED信息之后再次发起请 求，并不在Redis节点中完成请求转发；

1）计算槽

Redis首先需要计算键所对应的槽。根据键的有效部分使用CRC16 函数计算出散列值，再取对16383的余数，使每个键都可以映射到 0~16383槽范围内；

#cluster keyslot命令就是采用key_hash_slot函数实现的：127.0.0.1:6379> cluster keyslot key:test:111(integer) 10050127.0.0.1:6379> cluster keyslot key:{hash_tag}:111(integer) 2515127.0.0.1:6379> cluster keyslot key:{hash_tag}:222(integer) 2515

键内部使用大括号包含的内容又叫做hash_tag，它提供不同的键可以具备相同slot的功能，常用于Redis IO优化；

#例如在集群模式下使用mget等命令优化批量调用时，键列表必须具有相同的slot，否则会报错。这时可以利用hash_tag让不同的键具有相同的slot达到优化的目的：127.0.0.1:6385> mget user:10086:frends user:10086:videos(error) CROSSSLOT Keys in request don't hash to the same slot127.0.0.1:6385> mget user:{10086}:friends user:{10086}:videos1) "friends"2) "videos"

Pipeline同样可以受益于hash_tag，由于Pipeline只能向一个节点批量 发送执行命令，而相同slot必然会对应到唯一的节点，降低了集群使用Pipeline的门槛；

2）槽节点查找

Redis计算得到键对应的槽后，需要查找槽所对应的节点。集群内 通过消息交换每个节点都会知道所有节点的槽信息，内部保存在 clusterState结构中；

根据MOVED重定向机制， 客户端可以随机连接集群内任一Redis获取键所在节点，这种客户端又叫Dummy（傀儡）客户端

它优点：代码实现简单，对客户端协议影 响较小，只需要根据重定向信息再次发送请求即可。

它的弊端：每次执行键命令前都要到Redis上进行重定向才能找到要执行命令的节点，额外增加了IO开销，这不是Redis集群高效的使用方式。

通常集群客户端都采用另一种实现：Smart（智能）客户端

2.Smart客户端

Smart客户端通过在内部维护slot→node的映射关系，本地就 可实现键到节点的查找，从而保证IO效率的最大化，而MOVED重定向 负责协助Smart客户端更新slot→node映射。

1.smart客户端原理

以Java的Jedis为例，说 明Smart客户端操作集群的流程：

1）首先在JedisCluster初始化时会选择一个运行节点，初始化槽和 节点映射关系，使用cluster slots命令完成：

127.0.0.1:6379> cluster slots1) 1) (integer) 0 // 开始槽范围 2) (integer) 1365 // 结束槽范围 3) 1) "127.0.0.1" // 主节点ip2) (integer) 6385 // 主节点地址 4) 1) "127.0.0.1" // 从节点ip2) (integer) 6386 // 从节点端口2) 1) (integer) 5462 2) (integer) 68263) 1) "127.0.0.1" 2) (integer) 63854) 1) "127.0.0.1" 2) (integer) 6386...

2）JedisCluster解析cluster slots结果缓存在本地，并为每个节点创建 唯一的JedisPool连接池。映射关系在JedisClusterInfoCache类中：

public class JedisClusterInfoCache {private Map nodes = new HashMap();private Map slots = new HashMap();...}

3）JedisCluster执行键命令的过程有些复杂

键命令执行流程：

• 1）计算slot并根据slots缓存获取目标节点连接，发送命令
• 2）如果出现连接错误，使用随机连接重新执行键命令，每次命令 重试对redi-rections参数减1
• 3）捕获到MOVED重定向错误，使用cluster slots命令更新slots缓存 （renewSlotCache方法）
• 4）重复执行1）~3）步，直到命令执行成功，或者当 redirections<=0时抛出Jedis ClusterMaxRedirectionsException异常

Smart客户端成本和可能存在的问题分析：

1）客户端内部维护slots缓存表，并且针对每个节点维护连接池， 当集群规模非常大时，客户端会维护非常多的连接并消耗更多的内存

2）使用Jedis操作集群时最常见的错误是：

throw newJedisClusterMaxRedirectionsException(“Too many Cluster redirections”); 这经常会引起开发人员的疑惑，它隐藏了内部错误细节，原因是节 点宕机或请求超时都会抛出JedisConnectionException，导致触发了随机 重试，当重试次数耗尽抛出这个错误；

3）当出现JedisConnectionException时，Jedis认为可能是集群节点故 障需要随机重试来更新slots缓存，因此了解哪些异常将抛出 JedisConnectionException变得非常重要，有如下几种情况会抛出 JedisConnectionException：

• ·Jedis连接节点发生socket错误时抛出。
• ·所有命令/Lua脚本读写超时抛出。
• ·JedisPool连接池获取可用Jedis对象超时抛出。

前两点都可能是节点故障需要通过JedisConnectionException来更新 slots缓存，但是第三点没有必要，因此Jedis2.8.1版本之后对于连接池的 超时抛出Jedis Exception，从而避免触发随机重试机制；

4）Redis集群支持自动故障转移，但是从故障发现到完成转移需要 一定的时间，节点宕机期间所有指向这个节点的命令都会触发随机重 试，每次收到MOVED重定向后会调用JedisClusterInfoCache类的 renewSlotCache方法

获得写锁后再执行cluster slots命令初始化缓存，由于集群所有的键命令都会执行getSlotPool方法计算槽对应节点，它内部要求读锁。Reentrant ReadWriteLock是读锁共享且读写锁互斥，从而导致所有的请求都会造成阻塞。对于并发量高的场景将极大地影响集群吞吐。这个现象称为cluster slots风暴：

• ·重试机制导致IO通信放大问题

比如默认重试5次的情况，当抛出 JedisClusterMaxRedirectionsException异常时，内部最少需要9次IO通 信：5次发送命令+2次ping命令保证随机节点正常+2次cluster slots命令初 始化slots缓存。导致异常判定时间变长

• ·个别节点操作异常导致频繁的更新slots缓存

多次调用cluster slots 命令，高并发时将过度消耗Redis节点资源，如果集群slotnode映射庞 大则cluster slots返回信息越多，问题越严重

• ·频繁触发更新本地slots缓存操作，内部使用了写锁，阻塞对集群所有的键命令调用。

针对以上问题在Jedis2.8.2版本做了改进：

• ·当接收到JedisConnectionException时不再轻易初始化slots缓存，大幅降低内部IO次数
• ·当更新slots缓存时，不再使用ping命令检测节点活跃度，并且使用 redis covering变量保证同一时刻只有一个线程更新slots缓存，其他线程 忽略，优化了写锁阻塞和cluster slots调用次数
• 命令发送次数变为5次：4次重试命令+1次cluster slots命令，同时避 免了cluster slots不必要的并发调用

2.Smart客户端——JedisCluster

（1）JedisCluster的定义

Jedis为Redis Cluster提供了Smart客户端，对应的类是JedisCluster， 它的初始化方法如下：

public JedisCluster(Set jedisClusterNode, int connectionTimeout, intsoTimeout, int maxAttempts, final GenericObjectPoolConfig poolConfig) {...}

• ·SetjedisClusterNode：所有Redis Cluster节点信息 （也可以是一部分，因为客户端可以通过cluster slots自动发现）
• ·int connectionTimeout：连接超时。
• ·int soTimeout：读写超时。
• ·int maxAttempts：重试次数。
• ·GenericObjectPoolConfig poolConfig：连接池参数，JedisCluster会 为Redis Cluster的每个节点创建连接池

JedisCluster的初始化过程：

// 初始化所有节点(例如6个节点)Set jedisClusterNode = new HashSet();jedisClusterNode.add(new HostAndPort("10.10.xx.1", 6379));jedisClusterNode.add(new HostAndPort("10.10.xx.2", 6379));jedisClusterNode.add(new HostAndPort("10.10.xx.3", 6379));jedisClusterNode.add(new HostAndPort("10.10.xx.4", 6379));jedisClusterNode.add(new HostAndPort("10.10.xx.5", 6379));jedisClusterNode.add(new HostAndPort("10.10.xx.6", 6379));// 初始化commnon-pool连接池，并设置相关参数GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();// 初始化JedisClusterJedisCluster jedisCluster = new JedisCluster(jedisClusterNode, 1000, 1000, 5, poolConfig);

JedisCluster可以实现命令的调用：

jedisCluster.set("hello", "world");jedisCluster.get("key");

JedisCluster的使用需要注意以下几点：

• ·JedisCluster包含了所有节点的连接池（JedisPool），所以建议 JedisCluster使用单例
• ·JedisCluster每次操作完成后，不需要管理连接池的借还，它在内 部已经完成
• ·JedisCluster一般不要执行close（）操作，它会将所有JedisPool执行 destroy操作

（2）多节点命令和操作

Redis Cluster虽然提供了分布式的特性，但是有些命令或者操作， 诸如keys、flushall、删除指定模式的键，需要遍历所有节点才可以完成，从Redis Cluster删除指定模式键的功能：

// 从RedisCluster批量删除指定pattern的数据public void delRedisClusterByPattern(JedisCluster jedisCluster, String pattern,int scanCounter) {// 获取所有节点的JedisPoolMap jedisPoolMap = jedisCluster.getClusterNodes();for (Entry entry : jedisPoolMap.entrySet()) {// 获取每个节点的Jedis连接Jedis jedis = entry.getValue().getResource();// 只删除主节点数据if (!isMaster(jedis)) {continue;}// 使用Pipeline每次删除指定前缀的数据Pipeline pipeline = jedis.pipelined();// 使用scan扫描指定前缀的数据String cursor = "0";// 指定扫描参数：每次扫描个数和patternScanParams params = new ScanParams().count(scanCounter).match(pattern);while (true) {// 执行扫描ScanResult scanResult = jedis.scan(cursor, params);// 删除的key列表List keyList = scanResult.getResult();if (keyList != null && keyList.size() > 0) {for (String key : keyList) {pipeline.del(key);}// 批量删除pipeline.syncAndReturnAll();}cursor = scanResult.getStringCursor();// 如果游标变为0，说明扫描完毕if ("0".equals(cursor)) {break;}}}}// 判断当前Redis是否为master节点private boolean isMaster(Jedis jedis) {String[] data = jedis.info("Replication").split("\r\n");for (String line : data) {if ("role:master".equals(line.trim())) {return true;}}return false;}

具体分为如下几个步骤：

1）通过jedisCluster.getClusterNodes（）获取所有节点的连接池

2）使用info replication筛选1）中的主节点

3）遍历主节点，使用scan命令找到指定模式的key，使用Pipeline机 制删除

#每次遍历1000个key，将Redis Cluster中以user开头的key全部删除。String pattern = "user*";int scanCounter = 1000;delRedisClusterByPattern(jedisCluster, pattern, scanCounter);

keys、flushall等需要遍历所有节点的命令，同样可以参照 上面的方法进行相应功能的实现；

（3）批量操作的方法

Redis Cluster中，由于key分布到各个节点上，会造成无法实现 mget、mset等功能。但是可以利用CRC16算法计算出key对应的slot，以 及Smart客户端保存了slot和节点对应关系的特性，将属于同一个Redis节 点的key进行归档，然后分别对每个节点对应的子key列表执行mget或者 pipeline操作，下面文章我们会出具体使用方法；

（4）使用Lua、事务等特性的方法

Lua和事务需要所操作的key，必须在一个节点上，不过Redis Cluster提供了hashtag，如果开发人员确实要使用Lua或者事务，可以将 所要操作的key使用一个hashtag；

// hashtagString hastag = "{user}";// 用户A的关注表String userAFollowKey = hastag + ":a:follow";// 用户B的粉丝表String userBFanKey = hastag + ":b:fans";// 计算hashtag对应的slotint slot = JedisClusterCRC16.getSlot(hastag);// 获取指定slot的JedisPoolJedisPool jedisPool = jedisCluster.getConnectionHandler().getJedisPoolFromSlot(slot);// 在当个节点上执行事务Jedis jedis = null;try {jedis = jedisPool.getResource();// 用户A的关注表加入用户B，用户B的粉丝列表加入用户ATransaction transaction = jedis.multi();transaction.sadd(userAFollowKey, "user:b");transaction.sadd(userBFanKey, "user:a");transaction.exec();} catch (Exception e) {logger.error(e.getMessage(), e);} finally {if (jedis!= null)jedis.close();}

具体步骤如下：

1）将事务中所有的key添加hashtag

2）使用CRC16计算hashtag对应的slot

3）获取指定slot对应的节点连接池JedisPool

4）在JedisPool上执行事务

3.ASK重定向

Redis集群支持在线迁移槽（slot）和数据来完成水平伸缩，当slot对 应的数据从源节点到目标节点迁移过程中，客户端需要做到智能识别， 保证键命令可正常执行；

1.客户端ASK重定向流程

1）客户端根据本地slots缓存发送命令到源节点，如果存在键对象 则直接执行并返回结果给客户端

2）如果键对象不存在，则可能存在于目标节点，这时源节点会回 复ASK重定向异常。格式如下：（error）ASK{slot}{targetIP}： {targetPort}

3）客户端从ASK重定向异常提取出目标节点信息，发送asking命令 到目标节点打开客户端连接标识，再执行键命令。如果存在则执行，不 存在则返回不存在信息

ASK与MOVED的区别：
ASK重定向说明集群正在进行slot数据迁移，客户端无法知道什么时候迁移完成，因此只能是临时性的重定向，客户端不会更新slots缓存。但是MOVED重定向说明键对应的槽已经明确指定到新的节点，因此需要更新slots缓存。

2.节点内部处理

为了支持ASK重定向，源节点和目标节点在内部的clusterState结构 中维护当前正在迁移的槽信息，用于识别槽迁移情况：

typedef struct clusterState {clusterNode *myself; /* 自身节点*/clusterNode *slots[CLUSTER_SLOTS]; /* 槽和节点映射数组*/clusterNode *migrating_slots_to[CLUSTER_SLOTS];/* 正在迁出的槽节点数组*/clusterNode *importing_slots_from[CLUSTER_SLOTS];/* 正在迁入的槽节点数组*/...} clusterState;

节点每次接收到键命令时，都会根据clusterState内的迁移属性进行命令处理：

• ·如果键所在的槽由当前节点负责，但键不存在则查找 migrating_slots_to数组查看槽是否正在迁出，如果是返回ASK重定向。
• ·如果客户端发送asking命令打开了CLIENT_ASKING标识，则该客户端下次发送键命令时查找importing_slots_from数组获取clusterNode， 如果指向自身则执行命令。
• ·需要注意的是，asking命令是一次性命令，每次执行完后客户端标识都会修改回原状态，因此每次客户端接收到ASK重定向后都需要发送asking命令。
• ·批量操作。ASK重定向对单键命令支持得很完善，但是如mget或pipeline批量操作，当槽处于迁移状态时， 批量操作会受到影响；

当在集群环境下使用mget、mset等批量操作时，slot迁 移数据期间由于键列表无法保证在同一节点，会导致大量错误；Pipeline并没有直接抛出异常，可以借助于 JedisAskDataException内返回的目标节点信息，手动重定向请求给目标 节点，修改后的程序如下：

@Testpublic void pipelineOnAskTestV2() {JedisSlotBasedConnectionHandler connectionHandler = new JedisCluster(new HostAndPort("127.0.0.1", 6379)) {public JedisSlotBasedConnectionHandler getConnectionHandler() {return (JedisSlotBasedConnectionHandler) super.connectionHandler;}}.getConnectionHandler();List keys = Arrays.asList("key:test:68253", "key:test:79212", "key:test:5028");Jedis jedis = connectionHandler.getConnectionFromSlot(JedisClusterCRC16.getSlot(keys.get(2)));try {Pipeline pipelined = jedis.pipelined();for (String key : keys) {pipelined.get(key);}List