⽂章⽬录
1 概述
集，即Redis Cluster，是Redis 3.0开始引⼊的分布式存储⽅案。
集由多个节点(Node)组成，Redis的数据分布在这些节点中。集中的节点分为主节点和从节点：只有主节点负责读写请求和集信息的维护；从节点只进⾏主节点数据和状态信息的复制。 集的作⽤，可以归纳为两点：
1. 数据分区：数据分区(或称数据分⽚)是集最核⼼的功能。
集将数据分散到多个节点，⼀⽅⾯突破了Redis单机内存⼤⼩的限制，存储容量⼤⼤增加；另⼀⽅⾯每个主节点都可以对外提供读服务和写服务，⼤⼤提⾼了集的响应能⼒。
Redis单机内存⼤⼩受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太⼤，bgsave和bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间⽆法提供服务，全量复制阶段主节点的复制缓冲区可能溢出。
2. ⾼可⽤：集⽀持主从复制和主节点的⾃动故障转移（与哨兵类似）；当任⼀节点发⽣故障时，集仍然可以对外提供服务。
2 集搭建
虽然Redis cluster是Redis3引⼊的，但是Redis3的创建集⽅式有两种：
1. ⼀种是通过cluster node 查看集信息、通过cluster meet添加集节点、通过cluster replicate创建节点的主从结构。
2. ⼀种需要依赖ruby才能使⽤，redis-trib.rb。
虽然是分两种⽅式，但是如果要增加节点还是需要通过cluster meet。
因此基于Redis3来创建集还是限制还是很⼤，要么较为⿇烦，要么依赖ruby。
本节基于Redis5.0.3实现集搭建，Redis5脱离了对ruby的依赖，可以直接通过./redis-cli --cluster create来创建集。
2.1 创建配置
节点1:
cp /home/redis5.0.f /home/redis5.0.3/redis_f
cp /home/redis5.0.f /home/redis5.0.3/redis_f
节点2:
cp /home/redis5.0.f /home/redis5.0.3/redis_f
cp /home/redis5.0.f /home/redis5.0.3/redis_f
节点3:
cp /home/redis5.0.f /home/redis5.0.3/redis_f
cp /home/redis5.0.f /home/redis5.0.3/redis_f
2.2 启动服务
在每个节点执⾏：
/
home/redis/redis-5.0.3/src/redis-server /home/redis5.0.3/redis_f
/home/redis/redis-5.0.3/src/redis-server /home/redis5.0.3/redis_f
2.3 创建集
王的男人 李俊基
./redis-cli --cluster create 192.168.2.4:7000 192.168.2.5:7000 192.168.2.6:7000 192.168.2.4:7001 192.168.2.5:7001 192.168.2.6:7001 --cluster-replicas 1
创建成功：
2.4 哈希槽分配
⼀个redis集，所有的键会被分配在16384个插槽，在刚刚创建的集信息中：
通过上述信息可以看到，每个主数据库会负责处理其中的⼀部分插槽：汉阳铁厂博物馆
192.168.2.4:7000主节点负责处理[0-5460]插槽
192.168.2.5:7000主节点负责处理[5461-10922]插槽
192.168.2.6:7000主节点负责处理[10923-16383]插槽
虽然通过创建集初始化，⾃动分配插槽时是连续分配，但是这并不是⼀定的，可以通过命令来⼿动分配插槽，这些插槽可以是⾮连续的。
那么redis是如何确定将key分配给哪个插槽呢？⾸先Redis将每个键名的有效部分使⽤CRC16算法计算出散列值，然后对16384取余，这样就能获取指定槽位，并通过该槽位确定负责节点。这⾥需要特别之处有效部分的概念：
1. 如果键名包含⼤括号({})的内容，则有效部分是则是指这部分内容。
2. 如果不存在⼤括号内容，则整个键名都为有效部分。
例如：hello.world的有效部分就是“hello.world”；
{user102:}:last.name的有效部分为“user102”。
这⾥就有⼀种场景如果两个键的有效部分相同，则两个键存储在同⼀个插槽内，如{user102:}:last.name，{user102:}:first.name。则可以通过MGET {user102:}:last.name {user102:}:first.name来同时获取两个键的值。
除了通过./redis-cli --cluster create命令，让redis⾃动分配哈希槽以外，还有以下⼏种分配哈希槽的⽅式：
2.4.1 cluster meet 创建集（在集中添加节点）
如果是通过cluster meet ⽅式来创建集，通过cluster meet将节点添加到集中，就可以使⽤cluster addslots slot1 slot2 …[slotn]的⽅式来分配哈希槽，这⾥的哈希槽可以指定具体槽位，可以是⾮连续的。
2.4.2 cluster setlots命令
通过 cluster setlots 命令可以将指定的插槽号迁移到对应节点，这也能说明，插槽号的分配不⼀定是连续的。
cluster setlots 插槽号 NODE 新节点的运⾏id
这个命令只能在空槽的时候⽤，因为这样的操作只能转移槽为，槽中的键并不能⼀起连带转移，因此当客户端查该槽的键时，将会出现“丢失”的现象。 因此需要在使⽤该命令之前，需要先获取该槽中有哪些键，并将键转移到⽬标节点的其他槽中。并且在转移过程中，还需要处理客户端的请求，当数据转移未完成时，对请求做出正确的响应，这⾥正确的响应，并不⼀定⽼节点或者新节点，因为都有可能。为了解决这个问题，redis提供了处理机制，具体操作如下：
假设要把0号插槽从A迁移到B，此时redis-cli(⽼版本为redis-trib.rb)需要依次执⾏如下步骤：渣打小三
1. 在B执⾏cluster setslot 0 importing A;
2. 在A执⾏cluser setslot 0 migrating B;
3. 执⾏ cluster getkeysinslot 0 获取哈希槽对应的键列表，也就是该槽上的所有键。
4. 对每个键执⾏migrate命令，将其从A迁移到B；
migrate ⽬标节点地址⽬标节点端⼝键名数据库号码超时时间 [copy] [replace]
migrate 192.168.1.4 7000 abc 0 15999 replication
5. 执⾏cluster setlots 0 NODE B 完成迁移。
以上过程是哈希槽和键迁移的全过程，⽽redis是如何来处理客户端对迁移数据的请求的呢？
当A收到客户端请求，如果键存在（未发⽣迁移），则正常处理，否则返回⼀个ASK跳转请求，告诉客户端键在B中。
当B收到客户端请求，如果客户端接收过A发送的ASK命令，则直接返回键值内容，否则会返回MOVED跳转请求，让客户端发送到A请求数据。
2.5 集扩容
新节点接⼊集有两种⽅式：
1. 作为从节点
2. 作为主节点
2.5.1 从节点扩容
使⽤cluster replicate命令指定主节点即可：
cluster replicate <nodeid>
这时，集的哈希槽分布并不会变化。
2.5.2 主节点扩容
主节点扩容分为两部分：
1. 将节点添加到集中
2. 重新分配集哈希槽
执⾏命令：redis
居敬小学
-cli --cluster add-node 192.168.2.7:7000 192.168.2.4:7000 ，将192.168.2.7:7000节点添加到集中。其中
192.168.2.7:7000为新节点的ip和端⼝，192.168.2.4:7000为⽼节点的ip和端⼝。
[root@localhost 7000]# /usr/local/redis/redis-5.0.3/src/redis
-cli --cluster add-node 192.168.2.7:7000 192.168.2.4:7000
Adding node 192.168.2.7:7000 to cluster 192.168.2.4:7000
Performing Cluster Check (using node 192.168.2.4:7000)
M: 662809cf2d5bb138912dea7fb1e452f6e0f149da 192.168.2.4:7000
slots:[0-5460] (5461 slots) master
1 additional replica(s)
S: 194a31057d2e098483bcd2ad01e1bba6a1af6a7d 192.168.2.4:7001
slots: (0 slots) slave
replicates 7b5f6aa6dcb4d5aca4a94e57ddeea6971b38bba6
S: b0db47b7bbd3694596f293aa522488882e8fe647 192.168.2.5:7001
slots: (0 slots) slave
replicates 33206e9384297092b5b8a85c944f3564e5d983d7
M: 7b5f6aa6dcb4d5aca4a94e57ddeea6971b38bba6 192.168.2.5:7000
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
M: 33206e9384297092b5b8a85c944f3564e5d983d7 192.168.2.6:7000
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
铸造论坛S: 60a0f7ced303374d8b36e7aa219cbcd4ff5b0caf 192.168.2.6:7001
slots: (0 slots) slave
replicates 662809cf2d5bb138912dea7fb1e452f6e0f149da
[OK] All nodes agree about slots configuration.
Check for open slots…
Check slots coverage…
[OK] All 16384 slots covered.
Send CLUSTER MEET to node 192.168.2.7:7000 to make it join the cluster.
[OK] New node added correctly.
在⽼节点执⾏命令 cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:7
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:1
cluster_stats_messages_ping_sent:2831
cluster_stats_messages_pong_sent:2805
cluster_stats_messages_sent:5636
cluster_stats_messages_ping_received:2799
cluster_stats_messages_pong_received:2831
cluster_stats_messages_meet_received:6
cluster_stats_messages_received:5636
192.168.5.100:8001> cluster nodes
194a31057d2e098483bcd2ad01e1bba6a1af6a7d 192.168.2.4:7001@18006 slave
7b5f6aa6dcb4d5aca4a94e57ddeea6971b38bba6 0 1544883929000 6 connected
b0db47b7bbd3694596f293aa522488882e8fe647 192.168.2.5:7001@18004 slave
33206e9384297092b5b8a85c944f3564e5d983d7 0 1544883930910 4 connected
7b5f6aa6dcb4d5aca4a94e57ddeea6971b38bba6 192.168.2.5:7000@18002 master - 0 1544883929000 2 connected 5461-10922
33206e9384297092b5b8a85c944f3564e5d983d7 192.168.2.6:7000@18003 master - 0 1544883928000 3 connected 10923-16383
662809cf2d5bb138912dea7fb1e452f6e0f149da 192.168.2.4:7000@18001 myself,master - 0 1544883928000 1 connected 0-5460
fea53768189af3e3e4849038af13607f59ec84b0 192.168.2.7:7000@18007 master - 0 1544883927000 0 connected
60a0f7ced303374d8b36e7aa219cbcd4ff5b0caf 192.168.2.6:7001@18005 slave
662809cf2d5bb138912dea7fb1e452f6e0f149da 0 1544883929897 5 connected
分配插槽：
在⽼节点执⾏命令：–cluster reshard 192.168.2.7:7000
Performing Cluster Check (using node 192.168.2.4:7000)
M: 662809cf2d5bb138912dea7fb1e452f6e0f149da 192.168.2.4:7000
slots:[0-5460] (5461 slots) master
1 additional replica(s)
S: 194a31057d2e098483bcd2ad01e1bba6a1af6a7d 192.168.2.4:7001
slots: (0 slots) slave
replicates 7b5f6aa6dcb4d5aca4a94e57ddeea6971b38bba6
S: b0db47b7bbd3694596f293aa522488882e8fe647 192.168.2.5:7001
slots: (0 slots) slave
replicates 33206e9384297092b5b8a85c944f3564e5d983d7
M: 7b5f6aa6dcb4d5aca4a94e57ddeea6971b38bba6 192.168.2.5:7000
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
M: 33206e9384297092b5b8a85c944f3564e5d983d7 192.168.2.6:7000
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
M: fea53768189af3e3e4849038af13607f59ec84b0 192.168.2.7:7000
slots: (0 slots) master
S: 60a0f7ced303374d8b36e7aa219cbcd4ff5b0caf 192.168.2.6:7001北京龙源冷却技术有限公司
slots: (0 slots) slave
replicates 662809cf2d5bb138912dea7fb1e452f6e0f149da
[OK] All nodes agree about slots configuration.
Check for open slots…
Check slots coverage…
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)?
What is the receiving node ID?
最后⼀句会询问要分多少个槽出来（i⽐如1000）？分给哪个节点（192.168.2.7:7000）
How many slots do you want to move (from 1 to 16384)? 1000
What is the receiving node ID? fea53768189af3e3e4849038af13607f59ec84b0 这⾥的分配⽅式有两种：
1. 从单个节点拿出1000个哈希槽分配给新节点（done）
2. 从每个节点随机拿出平均分配的哈希槽分配给新节点（all）
上诉两种⽅式对应的
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: 662809cf2d5bb138912dea7fb1e452f6e0f149da
Source node #2: done
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议