11_Redis集群

本笔记来源于：尚硅谷Redis零基础到进阶，最强redis7教程，阳哥亲自带练（附redis面试题）
b站视频

文章来自：
https://github.com/loneasing/mynote

Redis集群

官网：
https://redis.io/docs/reference/cluster-spec/

Redis 集群是 Redis 数据库的分布式解决方案，它可以将数据分散存储在多个节点上，以支持大规模数据存储和高并发访问。

Redis 集群使用的是基于槽的分区策略，即将数据分成固定数量的槽，每个槽由一个主节点和多个从节点组成。客户端请求会根据键值的哈希值被路由到对应的槽上，从而实现数据的分布式存储和访问。同时，Redis 集群还提供了多种操作槽的命令，以支持集群的管理和维护。

Redis 集群的主要特点包括：

1. 分布式存储：Redis 集群将数据分散存储在多个节点上，每个节点负责处理一部分数据，从而实现数据的分布式存储和访问。集群可以扩展到数千个节点，以支持海量数据存储和高并发访问。建议控制在1000个以内的节点数。
2. 高可用性：Redis 集群通过多副本机制和自动故障转移机制，保证数据的可靠性和可用性。每个节点都有多个副本，其中一个副本为主节点，负责处理客户端请求，其他副本为从节点，负责复制主节点的数据。当主节点宕机时，从节点会自动选举一个新的主节点，以保证数据的连续性和可用性。
3. 数据自动分片：Redis 集群将数据自动分片存储在多个节点上，以实现数据的均衡分布和高效访问。每个节点都负责处理一部分数据，同时维护一份槽指派表，记录每个槽对应的主节点和从节点。客户端请求会根据键值的哈希值被路由到对应的槽上，从而实现数据的分布式存储和访问。
4. 支持在线扩容缩容：Redis 集群支持在线添加和删除节点，以扩展或缩小集群的容量，而无需停机或数据迁移。集群会自动将数据重新分片和迁移，以保证数据的连续性和可用性。
5. 负载均衡：Redis 集群通过智能路由算法，将客户端请求均匀地分发到不同的节点上，以实现负载均衡和性能优化。客户端可以通过集群模式下的代理节点（cluster-enabled proxy）进行连接，代理节点会自动将请求路由到正确的节点上。

1. redis集群槽位

官方

翻译：
集群的密钥空间被分成 16384 个槽，有效地设置了 16384 个主节点的集群大小上限 (但是，建议的最大节点大小约为 1000 个节点)。
集群中的每个主节点处理 16384 个哈希槽的一个子集。 当没有集群重新配置正在进行时 (即哈希槽从一个节点移动到另一个节点)，集群是稳定的。当集群稳定时，单个哈希槽将由单个节点提供服务(但是，服务节点可以有一个或多个副本，在网络分裂或故障的情况下替换它，并且可以用于扩展 读取陈旧数据是可接受的操作)。

在 Redis 集群中，槽位（slot）是将数据进行分片的基本单位，也是实现数据分布式存储和访问的重要机制。Redis 集群默认将 16384 个槽位均分给不同的节点，每个节点负责处理一部分槽位，从而实现数据的分布式存储和访问。

具体来说，Redis 集群使用哈希槽（hash slot）的方式将数据进行分片，每个槽对应着一个整数编号，从 0 开始，一直到 16383。每个节点会负责处理一部分槽位，同时维护一份槽指派表（slot map），记录每个槽对应的主节点和从节点。

客户端请求会==根据键值的哈希值被路由到对应的槽==上，从而实现数据的分布式存储和访问。具体来说，客户端会将键值的哈希值对 16384 取模，得到一个槽号，然后将请求发送到对应的槽所在的节点上。如果该节点是主节点，它会将请求处理后的结果返回给客户端；如果该节点是从节点，则会将请求转发给对应的主节点进行处理。

需要注意的是，槽的数量是固定的，因此如果需要扩展 Redis 集群的容量，就需要将一些槽移动到新的节点上，以实现数据的重新分片和迁移。Redis 集群提供了多种操作槽的命令，以支持集群的管理和维护。

2. redis集群分片

在 Redis 集群中，数据分片（sharding）是将数据划分成多个部分，分别存储在不同的节点上，从而实现分布式存储和访问的基本方式。Redis 集群使用哈希槽（hash slot）的方式将数据进行分片，每个节点负责处理一部分槽位，从而实现数据的分布式存储和访问。

具体来说，Redis 集群默认将 16384 个槽位均分给不同的节点，每个节点负责处理一部分槽位，同时维护一份槽指派表（slot map），记录每个槽对应的主节点和从节点。客户端请求会根据键值的哈希值被路由到对应的槽上，从而实现数据的分布式存储和访问。

数据分片能够提高 Redis 集群的容量和可用性，减少单节点的负载压力，并支持横向扩展和动态扩容。同时，数据分片也会带来一些挑战和问题，例如数据迁移、节点失效、一致性维护等方面的问题，需要进行合理的设计和实现。

数据分片和槽位的结构很容易添加或者删除节点，比如如果我想添加个节点D，我需要从节点A，B，C中得部分槽位到D上。如果我想一出节点A，需要将A中的槽移动到B和C节点上，然后将没有任何槽的节点从集群中移除即可。由于一个结点将哈希槽移动到另一个节点不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。

3. redis槽位映射

哈希取余分区

哈希取余分区是一种常见的数据分区技术，它将数据划分成多个分区，并将每个分区分配给集群中的不同节点，从而实现分布式存储和访问。

在哈希取余分区中，首先根据某个键的哈希值对分区总数取模，得到该键所在的分区编号，然后将该键存储在对应的节点上。当需要访问某个键值对时，同样通过哈希值计算得到该键所在的分区编号，然后访问对应的节点，从而实现数据的分布式访问。

哈希取余分区技术简单易懂，易于实现，可以较好地均衡数据在各个节点之间的分布，从而提高系统的可扩展性和可用性。但是，该技术存在数据倾斜和数据迁移等问题。如果某个键的哈希值对分区总数取模后恰好落在某个分区上，那么该分区的负载将会比其他分区更重，可能会导致性能问题。此外，在节点的动态扩容和缩容时，会需要进行数据迁移，对系统的稳定性和性能也会带来影响。

$\textcolor{blue}{\large 优点}$：简单粗暴，直接有效，只需要预估好数据规划好节点，例如3台、8台、10台，就能保证一段时间的数据 支撑。使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求 (并维护这些请求的信息)， 起到负载均衡+分而治之的作用。

$\textcolor{blue}{\large 缺点}$：原来规划好的节点，进行扩容或者缩容就比较麻烦了额，不管扩缩，每次数据变动导致节点有变动，映射关系需要重新进行计算，在服务器个数固定不变时没有问题，如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化: Hash(key)/3会 变成Hash(key) /?。此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。 某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。

一致性哈希算法分区

一致性Hash算法背景是在1997年由麻省理工学院提出的，设计目标是为了解决分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数不行了。

当服务器个数发生变动时，尽量减少影响客户端到服务器的映射关系。

算法三大步骤

$\textcolor{red}{\large 算法构建一致性哈希环}$

一致性哈希算法必然有个hash函数并按照算法产生hash值，这个算法的所有可能哈希值会构成一个全量集，这个集合可以成为一个hash空间[0,2^32-1]，这个是一个线性空间，但是在算法中，我们通过适当的逻辑控制将它首尾相连(O= 2^32),这样让它逻辑上形成了一个环形空间。
它也是按照使用取模的方法，前面笔记介绍的节点取模法是对节点（服务器）的数量进行取模。而一致性Hash算法是对2^32取模，简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0-2^32-1(即哈希值是一个32位无符号整形），整个哈希环如下图:整个空间按顺时针方向组织，圆环的正上方的点代表0，O点右侧的第一个点代表1，以此类推，2、3、4、……直到2^32-1，也就是说0点左侧的第一个点代表2^32-1，0和2个32-1在零点中方向重合，我们把这个由2^32个点组成的圆环称为Hash环。

$\textcolor{red}{\large 服务器IP节点映射}$

将集群中各个IP节点映射到环上的某一个位置。
将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置。假如4个节点NodeA、B、C、D，经过IP地址的哈希函数计算(hash(ip))，使用IP地址哈希后在环空间的位置如下:

$\textcolor{red}{\large key落到服务器的落键规则}$

当我们需要存储一个kv键值对时，首先计算key的hash值，hash(key)，将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上。
如我们有Object A、 Object B、 Object C. object D四个数据对象，经过哈希计算后，在环空间上的位置如下:根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上。

优点

$\textcolor{green}{\large 一致性哈希算法的容错性}$ ：假设Node C宕机，可以看到此时对象A、B、D不会受到影响。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器 （即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。简单说，就是C挂了，受到影响的只是B、C之间的数据且这些数据会转移到D进行存储。

$\textcolor{green}{\large 一致性哈希算法的扩展性}$

数据量增加了，需要增加一台节点NodeX，X的位置在A和B之间，那收到影响的也就是A到X之间的数据，重新把A到X的数据录入到X上即可，不会导致hash取余全部数据重新洗牌。

缺点

$\textcolor{green}{\large 一致性哈希算法的数据倾斜问题}$

一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上)问题，例如系统中只有两台服务器

小总结

为了在节点数目发生改变时尽可能少的迁移数据

将所有的存储节点排列在收尾相接的Hash环上，每个key在计算Hash后会顺时针找到临近的存储节点存放。而当有节点加入或退出时仅影响该节点在Hash环上顺时针相邻的后续节点。

$\textcolor{green}{\large 优点}$ ：加入和删除节点只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响。

$\textcolor{green}{\large 缺点}$ ：数据的分布和节点的位置有关，因为这些节点不是均匀的分布在哈希环上的，所以数据在进行存储时达不到均匀分布的效果。

哈希槽分区

HASH_SLOT = CRC16(key) mod 16384

哈希槽实质就是一个数组，数组[0, 2^14 - 1]形成hash slot空间。

为解决均匀分配的问题，在$\textcolor{red}{\large 数据和节点之间又加入了一层，把这层称为哈希槽(slot)，用于管理数据和节点之间的关系}$，现在就相当于节点上放的是槽，槽里面放的是数据。

一个集群只能有16384个槽，编号0-16383(0-2^14-1)。这些槽会分配给集群中的所有主节点，分配策略没有要求。

集群会记录节点和槽的对应关系，解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取模，余数是几key就落入对应的槽里。HASH_SLOT = CRC16(key) mod 16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

哈希槽计算

Redis集群中内置了16384个哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。当需要在Redis集群中放置一个key-valuel时，redis先对key使用crc16算法算出一个结果然后用结果对16384求余数[ CRC16(key) % 16384]，这样每个key都会对应一个编号在0-16383之间的哈希槽，也就是映射到某个节点上。如下代码，key之A、B在Node2， key之C落在Node3上

经典面试题：为什么Redis集群的最大槽数是16384个？

Redis集群并没有使用一致性hash而是引入了哈希槽的概念。Redis 集群有16384个哈希糟，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。但为什么哈希槽的数量是16384 (2^14）个呢？

CRC16算法产生的hash值有16bit，该算法可以产生2^16=65536个值。 换句话说值是分布在0～65535之间，有更大的65536不用为什么只用16384就够?

作者在做mod运算的时候，为什么不mod65536，而选择mod16384? $\textcolor{red}{\large HASH_SLOT = CRC16(key) mod 65536为什么没启用？}$

Redis原作者回答：https://github.com/redis/redis/issues/2576

说明1：

正常的心跳数据包带有节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置。
这意味着它们包含原始节点的插槽配置，该节点使用2k的空间和16k的插槽，但是会使用8k的空间（使用65k的插槽）。同时，由于其他设计折衷，Redis集群不太可能扩展到1000个以上的主节点。
因此16k处于正确的范围内，以确保每个主机具有足够的插槽，最多可容纳1000个矩阵，但数量足够少，可以轻松地将插槽配置作为原始位图传播。请注意，在小型群集中，位图将难以压缩，因为当N较小时，位图将设置的slot / N位占设置位的很大百分比。

说明2：
$\textcolor{red}{\large (1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。}$
在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。当槽位为65536时，这块的大小是:65536÷8÷1024=8kb

在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。当槽位为16384时，这块的大小是:16384∶8∶1024=2kb

因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。

$\textcolor{red}{\large (2)redis的集群主节点数量基本不可能超过1000个。}$
集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者不建议redis cluster节点数量超过1000个。那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。

$\textcolor{red}{\large (3)槽位越小，节点少的情况下，压缩比高，容易传输}$
Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率slots /N很高的话(N表示节点数)， bitmap的压缩率就很低。如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

计算结论

Redis集群中内置了16384个哈希槽，redis会根据节点数量大致均等的将哈希槽映射到不同的节点。当需要在Redis集群中放置-一个key-value时， redis先对key使用crc16算法算出一个结果然后用结果对16384求余数[ CRC16(key) % 16384]， 这样每个key都会对应一个编号在0-16383之间的哈希槽，也就是映射到某个节点上。如下代码，key之A、B在Node2， key之C落在Node3上

Redis集群不保证强一致性

redis集群$\textcolor{red}{\large 不保证强一致性}$，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入请求命令

4. 集群环境搭建

（1）三主三从redis集群配置

由于机器性能有限，这里只配置了三台虚拟机，一台虚拟机配置两个redis实例

192.168.101.110 (下面简称110)配置端口为6381和6382两个实例，配置文件分别为cluster6381.conf和cluster6382.conf
192.168.101.111 (下面简称111)配置端口为6383和6384两个实例，配置文件分别为cluster6383.conf和cluster6384.conf
192.168.101.112 (下面简称112)配置端口为6385和6386两个实例，配置文件分别为cluster6385.conf和cluster6386.conf

以实例cluster6381.conf为例，配置文件内容如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

bind 0.0.0.0
daemonize yes
protected-mode no
port 6381
logfile "/myredis/cluster/cluster6381.log"
pidfile /myredis/ccluster6381.pid
dir /myredis/cluster
dbfilename dump6381.rdb
appendonly yes
appendfilename "appendonly6381.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes		# 开启集群
cluster-config-file nodes-6381.conf		# 集群生成的配置文件
cluster-node-timeout 5000	# 集群节点之间的超时时间

在每台虚拟机的根目录创建/myredis/cluster目录，然后在该目录创建两个配置文件：

查看cluster6381.conf文件内容：

（2）启动六台redis实例

启动集群实例和之前启动redis实例一样，只不过配置文件中配置了开启集群，会以集群的方式启动redis实例。

（3）构建主从关系

使用命令构建集群间的主从关系：**redis-cli -a 密码 --cluster create --cluster-replicas 1 IP:端口号 [IP:端口号]**

选项–replicas 1 表示我们希望为集群中的每个主节点创建一个从节点

IP:端口号是redis实例的地址和端口号，多个redis实例构成一个集群

主从关系是随机分配的(个人见解：一般按照输入的顺序基数位为master，偶数位为slave)，其master-slave关系是随机分配的。

在任意一个虚拟机中执行这个命令都可以，下面在110虚拟机中执行此命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

[root@redis cluster]# redis-cli -a 123456 --cluster create --cluster-replicas 1 192.168.101.110:6381 192.168.101.110:6382 192.168.101.111:6383 192.168.101.111:6384 192.168.101.112:6385 192.168.101.112:6386
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460			# 1号主节点分配了0-5460的槽位
Master[1] -> Slots 5461 - 10922		# 2号主节点分配了5461-10922的槽位
Master[2] -> Slots 10923 - 16383	# 3号主节点分配了10923-16383的槽位
Adding replica 192.168.101.111:6384 to 192.168.101.110:6381	#111机器的6384实例同步110机器的6381实例
Adding replica 192.168.101.112:6386 to 192.168.101.111:6383	#112机器的6386实例同步111机器的6383实例
Adding replica 192.168.101.110:6382 to 192.168.101.112:6385	#110机器的6382实例同步112机器的6385实例
M: e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6 192.168.101.110:6381	# 主节点id IP:端口号
   slots:[0-5460] (5461 slots) master	# 分配了5461个槽位
S: 202075b6488c250e6f8227c44b905f7781162f30 192.168.101.110:6382	# 从节点id IP:端口号
   replicates 154d23ad6fb321801ebe84e8066411e3f3fc05ec	# 从属154d23(主节点id，对应6385)
M: 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d 192.168.101.111:6383
   slots:[5461-10922] (5462 slots) master
S: 851c4e7c78ddfb59672dcdfae5e29a2372fdc192 192.168.101.111:6384
   replicates e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6
M: 154d23ad6fb321801ebe84e8066411e3f3fc05ec 192.168.101.112:6385
   slots:[10923-16383] (5461 slots) master
S: e2512f82160d0e044b40dade1f6e2df7a942c83c 192.168.101.112:6386
   replicates 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d
Can I set the above configuration? (type 'yes' to accept): yes	# 是否保存这些配置，输入yes保存
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
..
>>> Performing Cluster Check (using node 192.168.101.110:6381)
M: e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6 192.168.101.110:6381
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
S: 851c4e7c78ddfb59672dcdfae5e29a2372fdc192 192.168.101.111:6384
   slots: (0 slots) slave	# 从节点分配了0个槽位
   replicates e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6
M: 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d 192.168.101.111:6383
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: 202075b6488c250e6f8227c44b905f7781162f30 192.168.101.110:6382
   slots: (0 slots) slave
   replicates 154d23ad6fb321801ebe84e8066411e3f3fc05ec
S: e2512f82160d0e044b40dade1f6e2df7a942c83c 192.168.101.112:6386
   slots: (0 slots) slave
   replicates 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d
M: 154d23ad6fb321801ebe84e8066411e3f3fc05ec 192.168.101.112:6385
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

重连6381实例，查看并检验集群状态：CLUSTER INFO

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

[root@redis cluster]# redis-cli -a 123456 -p 6381
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6381> 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:6
cluster_my_epoch:1
cluster_stats_messages_ping_sent:3652
cluster_stats_messages_pong_sent:3675
cluster_stats_messages_sent:7327
cluster_stats_messages_ping_received:3670
cluster_stats_messages_pong_received:3652
cluster_stats_messages_meet_received:5
cluster_stats_messages_received:7327
total_cluster_links_buffer_limit_exceeded:0

查看集群节点的状态信息：

info replication

CLUSTER NODES

1
2
3
4
5
6
7
8
9

[root@redis cluster]# redis-cli -a 123456 -p 6381
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6381> CLUSTER NODES	# 查看集群节点状态信息
e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6 192.168.101.110:6381@16381 myself,master - 0 1681569469000 1 connected 0-5460	# myself,master表示当前所在的节点，是主节点。前面的一大串是该节点的id、IP端口信息
851c4e7c78ddfb59672dcdfae5e29a2372fdc192 192.168.101.111:6384@16384 slave e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6 0 1681569472503 1 connected	# 从节点851c41(6384)同步e4d44f(6381)
1b9c2607caafa82ab53a407f4979b00c9ee1ea9d 192.168.101.111:6383@16383 master - 0 1681569472000 3 connected 5461-10922
202075b6488c250e6f8227c44b905f7781162f30 192.168.101.110:6382@16382 slave 154d23ad6fb321801ebe84e8066411e3f3fc05ec 0 1681569472000 5 connected
e2512f82160d0e044b40dade1f6e2df7a942c83c 192.168.101.112:6386@16386 slave 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d 0 1681569472503 3 connected
154d23ad6fb321801ebe84e8066411e3f3fc05ec 192.168.101.112:6385@16385 master - 0 1681569472604 5 connected 10923-16383

CLUSTER INFO

5. 测试集群读写

每个key都有自己的哈希值，根据哈希值通过某种算法算出对应的槽位，该key只能存储到该槽位所在的节点上。

然而这种情况并不是我们想要的，可以在连接redis客户端时添加-c参数，这样会帮我们把数据路由到指定的槽位上，即使在不同的节点上也能随便存储数据。

查看某个key对应的槽位值：CLUSTER KEYSLOT key

任何字符都有对应的哈希值，所以任何字符都能计算出对应的槽位

查看某个槽位是否被占用：CLUSTER COUNTKEYSINSLOT 槽位号

返回1表示该槽位被占用；返回0表示该槽位没有被占用。

6. 测试集群主从切换

• 首先查看当前节点主从关系：INFO REPLICATION

  

• 手动关闭主节点6381，查看集群节点状态

  在其他任何集群节点查看集群节点的状态都可以。
  主节点宕机后，从节点会成为新的master。

• 重新连接节点6381，查看集群节点状态

  恢复6381节点后，该节点会变成新master的slave。

  

• 恢复6381master的身份：CLUSTER FAILOVER

  使用cluster failover可以恢复发生故障前的主从关系

  

7. redis集群扩容

在112虚拟机上新建两个redis实例6387和6388，此时112虚拟机上有4个redis实例分别是6385、6386、6387、6388

启动这两个新节点，此时它们都是master

将6387节点作为master加入到集群中：**redis-cli -a 密码 --cluster add-node IP:port IP:port**

前者IP:port为需要加入到集群的节点ip和端口
后者IP:port指集群中任一节点的ip和端口（可以理解为推荐人）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

[root@redis2 cluster]# redis-cli -a 123456 --cluster add-node 192.168.101.112:6387 192.168.101.110:6381
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Adding node 192.168.101.112:6387 to cluster 192.168.101.110:6381
>>> Performing Cluster Check (using node 192.168.101.110:6381)
M: e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6 192.168.101.110:6381
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
M: 154d23ad6fb321801ebe84e8066411e3f3fc05ec 192.168.101.112:6385
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
M: 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d 192.168.101.111:6383
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: e2512f82160d0e044b40dade1f6e2df7a942c83c 192.168.101.112:6386
   slots: (0 slots) slave
   replicates 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d
S: 202075b6488c250e6f8227c44b905f7781162f30 192.168.101.110:6382
   slots: (0 slots) slave
   replicates 154d23ad6fb321801ebe84e8066411e3f3fc05ec
S: 851c4e7c78ddfb59672dcdfae5e29a2372fdc192 192.168.101.111:6384
   slots: (0 slots) slave
   replicates e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
>>> Getting functions from cluster
>>> Send FUNCTION LIST to 192.168.101.112:6387 to verify there is no functions in it
>>> Send FUNCTION RESTORE to 192.168.101.112:6387
>>> Send CLUSTER MEET to node 192.168.101.112:6387 to make it join the cluster.
[OK] New node added correctly.

检查集群情况：**redis-cli -a 密码 --cluster check IP:port**

只需要指定集群中任意一个在线的节点的地址(IP:端口号)， 就会自动找到集群中的其他节点，即可查看整个集群的信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

[root@redis1 ~]# redis-cli -a 123456 --cluster check 192.168.101.110:6381
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.101.110:6381 (e4d44fbd...) -> 2 keys | 5461 slots | 1 slaves.
192.168.101.112:6385 (154d23ad...) -> 1 keys | 5461 slots | 1 slaves.
192.168.101.112:6387 (b1ef21d8...) -> 0 keys | 0 slots | 0 slaves.	#可以看到节点6387加入了集群但是没有分配槽位
192.168.101.111:6383 (1b9c2607...) -> 1 keys | 5462 slots | 1 slaves.
[OK] 4 keys in 4 masters.
0.00 keys per slot on average.
>>> Performing Cluster Check (using node 192.168.101.110:6381)
M: e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6 192.168.101.110:6381
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
M: 154d23ad6fb321801ebe84e8066411e3f3fc05ec 192.168.101.112:6385
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
M: b1ef21d88293bc1560f61a46c4fca8b601d59d60 192.168.101.112:6387
   slots: (0 slots) master
M: 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d 192.168.101.111:6383
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: e2512f82160d0e044b40dade1f6e2df7a942c83c 192.168.101.112:6386
   slots: (0 slots) slave
   replicates 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d
S: 202075b6488c250e6f8227c44b905f7781162f30 192.168.101.110:6382
   slots: (0 slots) slave
   replicates 154d23ad6fb321801ebe84e8066411e3f3fc05ec
S: 851c4e7c78ddfb59672dcdfae5e29a2372fdc192 192.168.101.111:6384
   slots: (0 slots) slave
   replicates e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

重新分派槽号：**redis-cli -a 密码 --cluster reshard IP:port**

只需要指定集群中任意一个在线的节点的地址(IP:端口号)即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

[root@redis2 cluster]# redis-cli -a 123456 --cluster reshard 192.168.101.110:6381
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Performing Cluster Check (using node 192.168.101.110:6381)
M: e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6 192.168.101.110:6381
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
M: 154d23ad6fb321801ebe84e8066411e3f3fc05ec 192.168.101.112:6385
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
M: b1ef21d88293bc1560f61a46c4fca8b601d59d60 192.168.101.112:6387
   slots: (0 slots) master  # 注意这里：此ip端口的redis是接收槽位的位置
M: 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d 192.168.101.111:6383
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: e2512f82160d0e044b40dade1f6e2df7a942c83c 192.168.101.112:6386
   slots: (0 slots) slave
   replicates 1b9c2607caafa82ab53a407f4979b00c9ee1ea9d
S: 202075b6488c250e6f8227c44b905f7781162f30 192.168.101.110:6382
   slots: (0 slots) slave
   replicates 154d23ad6fb321801ebe84e8066411e3f3fc05ec
S: 851c4e7c78ddfb59672dcdfae5e29a2372fdc192 192.168.101.111:6384
   slots: (0 slots) slave
   replicates e4d44fbdc683d3882b39f7b02d5a78bc4c0b36a6
[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)? 4096
What is the receiving node ID? b1ef21d88293bc1560f61a46c4fca8b601d59d60	# 指定一个节点id接收槽位
Please enter all the source node IDs.
  # all表示现有的三个分片平均拿出一点槽位分给新节点
  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: all

Ready to move 4096 slots.

再次检查集群情况

为什么6387是3个新的区间，以前的还是连续？

重新分配成本太高，所以前3家各自匀出来一部分，从6381/6383/6385三个旧节点分别匀出1367个坑位给信节点6387

为集群中新主节点添加从节点：
redis-cli -a 密码 --cluster add-node IP:port IP:port --cluster-slave --cluster-master-id 新主节点id

前者IP:port指从节点的地址，后者IP:port为集群中任意一个在线节点的地址

1
2
3
4

[root@redis2 cluster]# redis-cli -a 123456 --cluster add-node 192.168.101.112:6388 192.168.101.112:6387 --cluster-slave --cluster-master-id b1ef21d88293bc1560f61a46c4fca8b601d59d60
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Adding node 192.168.101.112:6388 to cluster 192.168.101.112:6387
>>> Performing Cluster Check (using node 192.168.101.112:6387)

再次检查集群情况

8. redis集群缩容

首先先将从节点6388删除：**redis-cli -a 密码 --cluster del-node IP:从节点端口 从节点id**

节点id可以通过检查集群情况命令查看：redis-cli -a 密码 --cluster check IP:port
也可以通过CLUSTER NODES命令查看。

1
2
3
4
5

[root@redis2 cluster]# redis-cli -a 123456 --cluster del-node 192.168.101.112:6388 8bc4986317910e2f57d67609931645b41d5a90e3		# 删除6388j
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Removing node 8bc4986317910e2f57d67609931645b41d5a90e3 from cluster 192.168.101.112:6388
>>> Sending CLUSTER FORGET messages to the cluster...
>>> Sending CLUSTER RESET SOFT to the deleted node.

将主节点6387的槽号清空重新分配

这里将清空的槽号全部分配给6381节点（当然也可以平均分配回之前的三个主节点，只不过要操作三次）

1
2

# 重新分配槽号
[root@redis2 cluster]# redis-cli -a 123456 --cluster reshard 192.168.101.110:6381

移除槽位后检查集群情况

6387节点槽位被清空，成为了6381节点的从节点

这和加入6387节点到集群时填写的集群中的IP:port有关（6381相当于推荐人）

此时节点6387是一个从节点，将节点6387删除

1

[root@redis2 cluster]# redis-cli -a 123456 --cluster del-node 192.168.101.112:6387 b1ef21d88293bc1560f61a46c4fca8b601d59d60

再次检查集群情况

9. 集群常用操作命令和CRC16算法分析

不在同一个slot槽位下的多键操作支持不好，通识占位符登场

不在同一个slot槽位下的键值无法使用mset、mget等多键操作

可以通过{}来定义同一个组的概念，使key中{}内相同内容的键值对放到一个slot槽位去，对照下图类似k1k2k3都映射为x，自然槽位一样

Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽。

CRC16源码浅谈

cluster.c源码分析一下

常用命令

• 集群是否完整才能对外提供服务

默认YES，现在集群架构是3主3从的redis cluster由3个master平分16384个slot，每个master的小集群负责1/3的slot，对应一部分数据。cluster-require-full-coverage:默认值yes，即需要集群完整性，方可对外提供服务通常情况，如果这3个小集群中，任何一个(1主1从）挂了，你这个集群对外可提供的数据只有2/3了，整个集群是不完整的， redis默认在这种情况下，是不会对外提供服务的。
如果你的诉求是，集群不完整的话也需要对外提供服务，需要将该参数设置为no，这样的话你挂了的那个小集群是不行了，但是其他的小集群仍然可以对外提供服务。

cluster-require-full-coverage

• CLUSTER COUNTKEYSINSLOT 槽位数字编号 CLUSTER COUNTKEYSINSLOT 12706
  返回结果：
  1 该槽位被占用
  0 该槽位没有被占用
• CLUSTER KEYSLOT 键名称
  CLUSTER KEYSLOT k1
  返回对应key的槽位数据，key不存在则返回0