Redis cluster 集群

一、Redis cluster集群介绍

在生产环境由于数据量过大，单个Master复制集难以承担，因此需要对多个复制集进行集群，形成水平扩展每个复制集只负责存储整个数据集的一部分，这就是Redis的集群，其作用是提供在多个Redis节点间共享数据的程序集。
官网参数地址如下：https://redis.io/docs/reference/cluster-spec/，模型如下图：

注意：

• Redis集群是一个提供在多个Redis节点间共享数据的程序集
• Redis集群可以支持多个Master，上图就有三个master

二、Redis cluster集群能做什么？

1.Redis集群支持多个Master，每个Master又可以挂载多个Slave，

• 读写分离
• 支持数据的高可用
• 支持海量数据的读写存储操作

2.由于Cluster自带Sentinel的故障转移机制，内置了高可用的支持，无需再去使用哨兵功能

3.客户端与Redis的节点连接，不再需要连接集群中所有的节点，只需要任意连接集群中的一个可用节点即可

4.槽位slot负责分配到各个物理服务节点，由对应的集群来负责维护节点、插槽和数据之间的关系

三、关于集群算法中分片和槽位slot说明

3.1.密钥分配模式

集群的密钥空间被分割成16384个槽，有效地设定了16384个主节点的集群规模上限（然而，建议的最大节点规模是在~1000个节点的数量级上）。

集群中的每个主节点处理16384个哈希槽的一个子集。当没有正在进行的集群重新配置（即哈希槽从一个节点移到另一个节点）时，集群是稳定的。当集群稳定时，单个哈希槽将由单个节点提供服务（然而，提供服务的节点可以有一个或多个副本，在网络分裂或失败的情况下，这些副本将取代它，并且可以用来扩展读取陈旧数据的操作。）

上述内容来源自redis官网说明如下图

3.2.redis集群的槽位slot

Redis集群没有使用一致性hash, 而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽，例如当前集群有3个master节点,那么槽位如下分配：

3.3.redis集群的分片

分片是什么？

使用Redis集群时我们会将存储的数据分散到多台redis机器上，这称为分片。简言之，集群中的每个Redis实例都被认为是整个数据的一个分片。

如何找到给定写入key的分片？

为了找到给定key的分片，需要对key进行CRC16(key)算法处理并通过对总分片数量取模。然后，使用确定性哈希函数，这意味着给定的key将多次始终映射到同一个分片，就可以以此推断将来读取特定key的位置。

3.4.redis集群采用槽位和分片机制 有什么样的优点？

采用槽位和分片机制最大优势，后期redis集群方便扩缩容和数据分派查找，这种结构很容易添加或者删除节点，例如想添加一个新的master节点D，只需要从已有的master节点A、B、C中获取部分槽位（每个上面均一部分），分配到D上即可，想移除master节点A，只需要将A中的槽位移到B和C节点上，然后将没有任何槽的A节点从集群中移除即可，由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群出现不可用的状态。

3.5.slot槽位映射的实现

slot槽位映射，一般业界有3种解决方案，分别是：哈希取余分区、一致性哈希算法分区、哈希槽分区，而redis中操作的是哈希槽分区的方案，下面对于对于这个三个方案的说明。

3.5.1.哈希取余分区

例如有1亿条记录就是1亿个k,v，单机处理不了这么对数据，就必须要采用分布式集群的方式，假设有3台机器构成一个集群，用户每次读写操作都是根据公式：

# 计算出哈希值，用来决定数据映射到哪一个节点上
hash(key) % N个机器台数

优点：

简单粗暴容易操作，直接有效，只需要预估好数据规划好master节点数量，例如3台、9台、11台，就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡和分而治之的作用。

缺点：
原来规划好的节点，进行扩容或者缩容就比较麻烦了额，无论是扩缩容，每次数据变动导致节点有变动，映射关系需要重新进行计算，在服务器个数固定不变时没有问题，如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化：

Hash(key)/3 会变成 Hash(key) /?。

此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。同时如果发生某个redis机器宕机了，由于主机台数数量变化，会导致hash取余全部数据重新洗牌。

3.5.2.一致性哈希算法分区

1.一致性哈希算法分区是什么？有什么作用？

• 一致性哈希算法在1997年由麻省理工学院中提出的，设计目标是为了解决分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数没办法执行了。
• 提出一致性Hash解决方案。目的是当服务器个数发生变动时，尽量减少影响客户端到服务器的映射关系

2.一致性哈希算法分区的三个步骤

• 步骤一：算法构建一致性哈希环

一致性哈希算法必然有个hash函数并按照算法产生hash值，这个算法的所有可能哈希值会构成一个全量集，这个集合可以成为一个hash空间[0,2^32-1]，这个是一个线性空间，但是在算法中，我们通过适当的逻辑控制将它首尾相连(0 = 2^32),这样让它逻辑上形成了一个环形空间。

它也是按照使用取模的方法，前面介绍的节点取模法是对节点（服务器）的数量进行取模。而一致性Hash算法是对2^32取模，简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数的值空间为0-2^32-1（即哈希值是一个32位无符号整形），整个哈希环如下图：整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、……直到2^32-1，也就是说0点左侧的第一个点代表2^32-1， 0和2^32-1在零点中方向重合，我们把这个由2^32个点组成的圆环称为Hash环。

• 步骤二：redis服务器IP节点映射

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

• 步骤三：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上。

3.一致性哈希算法分区优点是什么？

有点有下面两个，分别是：

• 一致性哈希算法的容错性

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

• 一致性哈希算法的扩展性

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

4.一致性哈希算法分区的缺点是什么？

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

5.对于一致性哈希算法分区的小结

• 为了在节点数目发生改变时尽可能少的迁移数据将所有的存储节点排列在收尾相接的Hash环上，每个key在计算Hash后会顺时针找到临近的存储节点存放。而当有节点加入或退出时仅影响该节点在Hash环上顺时针相邻的后续节点。
• 优点：加入和删除节点只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响。
• 缺点：数据的分布和节点的位置有关，因为这些节点不是均匀的分布在哈希环上的，所以数据在进行存储时达不到均匀分布的效果。

3.5.2.哈希槽分区

1.为什么会出现哈希槽分区？哈希槽分区能做什么？

是因为一致性哈希算法分区存在数据倾斜的问题，哈希槽实质就是一个数组，数组[0,2^14 -1]形成hash slot空间。
解决了均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据。

槽解决的是粒度问题，相当于把粒度变大，这样便于数据移动。哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配

2.哈希槽分区多少个hash槽？

一个集群只能有16384个槽，编号0-16383（0-2^14-1）。这些槽会分配给集群中的所有主节点，分配策略没有要求。
集群会记录节点和槽的对应关系，解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取模，余数是几key就落入对应的槽里。HASH_SLOT = CRC16(key) mod 16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

3.6.slot槽位分区的常见问题说明

为什么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？ HASH_SLOT = CRC16(key) mod 65536为什么没启用？

上述的问题，作者是在GitHub上做过回答：https://github.com/redis/redis/issues/2576，翻译后意思如下：

• 正常的心跳包携带一个节点的完整配置，可以以幂等的方式替换旧的配置，以更新旧的配置。这意味着它们包含节点的插槽配置，以原始形式使用2k空间和16k插槽，但使用65k插槽将使用8k空间。
• 同时，由于其他设计权衡，Redis集群不太可能扩展到超过1000个主节点。
• 所以16k在正确的范围内，以确保每个master有足够的插槽，最多有1000个mater，但这个数字足够小，可以很容易地将插槽配置传播为原始位图。注意，在小的集群中，位图将很难压缩，因为当N很小时，位图将设置槽位/N位，这是一个很大的百分比

对于上述内容信息总结如下：

(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消息的消息头太大了，浪费带宽。
(2)redis的集群主节点数量基本不可能超过1000个。
集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者不建议redis cluster节点数量超过1000个。 那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。
(3)槽位越小，节点少的情况下，压缩比高，容易传输
Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。 如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

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

使用了redis集群能保证数据的强一致性吗？

Redis集群不保证强一致性，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入数据请求命令。

四、集群环境案例步骤

3.1. 三台master三台slave的redis集群配置

3.1.1.创建redis配置文件的存放路径

在3台虚拟机，各自新建目录，用于存放redis的配置文件：

mkdir -p /myredis/cluster

3.1.2.分别在3台虚拟机创建6个独立的redis实例服务

主机ip	对应master端口	对应slave端口
192.168.42.132	6381	6382
192.168.42.135	6383	6384
192.168.42.135	6385	6386

（1）在192.168.42.132上准备端口6381表示master和端口6382表示对应的salve，配置信息如下：

• 通过 vim  /myredis/cluster/redisCluster6381.conf 打开新建如下内容：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6381
logfile "/myredis/cluster/cluster6381.log"
pidfile /myredis/cluster6381.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

• 通过 vim  /myredis/cluster/redisCluster6382.conf 命令创建文件，内容如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6382
logfile "/myredis/cluster/cluster6382.log"
pidfile /myredis/cluster6382.pid
dir /myredis/cluster
dbfilename dump6382.rdb
appendonly yes
appendfilename "appendonly6382.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000

（2）在192.168.42.134上准备端口6383表示master和端口6384表示对应的salve，配置信息如下：

• 通过 vim  /myredis/cluster/redisCluster6383.conf 命令创建文件，内容如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6383
logfile "/myredis/cluster/cluster6383.log"
pidfile /myredis/cluster6383.pid
dir /myredis/cluster
dbfilename dump6383.rdb
appendonly yes
appendfilename "appendonly6383.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6383.conf
cluster-node-timeout 5000

• 通过 vim  /myredis/cluster/redisCluster6384.conf 命令创建文件，内容如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6384
logfile "/myredis/cluster/cluster6384.log"
pidfile /myredis/cluster6384.pid
dir /myredis/cluster
dbfilename dump6384.rdb
appendonly yes
appendfilename "appendonly6384.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6384.conf
cluster-node-timeout 5000

（3）在192.168.42.135上准备端口6385表示master和端口6386表示对应的salve，配置信息如下：

• 通过 vim  /myredis/cluster/redisCluster6385.conf 命令创建文件，内容如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6385
logfile "/myredis/cluster/cluster6385.log"
pidfile /myredis/cluster6385.pid
dir /myredis/cluster
dbfilename dump6385.rdb
appendonly yes
appendfilename "appendonly6385.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6385.conf
cluster-node-timeout 5000

• 通过 vim  /myredis/cluster/redisCluster6386.conf 命令创建文件，内容如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6386
logfile "/myredis/cluster/cluster6386.log"
pidfile /myredis/cluster6386.pid
dir /myredis/cluster
dbfilename dump6386.rdb
appendonly yes
appendfilename "appendonly6386.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6386.conf
cluster-node-timeout 5000

（4）分别启动上述的6个redis

# 以启动6381为案例，命令如下：
redis-server /myredis/cluster/redisCluster6381.conf

3.1.3.通过redis-cli命令为6台redis机器构建集群关系

构建主从关系命令（这里具体自己的虚拟机真实IP地址），命令如下：

redis-cli -a 123456 --cluster create --cluster-replicas 1 192.168.42.132:6381 192.168.42.132:6382 192.168.42.134:6383 192.168.42.134:6384 192.168.42.135:6385 192.168.42.135:6386

注意：

• --cluster-replicas 1 表示为每个master创建一个slave节点，
• 每个Redis集群中的节点都需要打开两个TCP连接。一个连接用于正常的给Client提供服务，比如6379，还有一个额外的端口（通过在这个端口号上加10000）作为数据端口，例如：redis的端口为6379，那么另外一个需要开通的端口是：6379 + 10000， 即需要开启 16379。16379端口用于集群总线，这是一个用二进制协议的点对点通信信道。这个集群总线（Cluster bus）用于节点的失败侦测、配置更新、故障转移授权，等等。
• 所以本次案例需要开启的端口有6381、16381、6382、16382、6383、16383、6384、16384、6385、16385、6386、16386共12个端口，如果不开启，则会一直等待连接

同时三条虚拟机的redis端口，要允许访问才行，防火墙设置如下：

# 开启
service firewalld start
# 重启
service firewalld restart
# 关闭
service firewalld stop
# 开放端口
firewall-cmd --permanent --add-port=6381/tcp
#重启防火墙(修改配置后要重启防火墙)
firewall-cmd --reload

执行如下图：

查看会生成集群的配置文件：

3.1.4.登录进入6381作为切入点，查看并检验集群状态

（1）.查看节点状态：

（2）.查看集群参数：cluster info

 CLUSTER INFO 命令使用 INFO 风格的形式展现了关于Redis集群的重要参数，如下图：

上述相关参数含义如下：

• cluster_state: ok状态表示集群可以正常接受查询请求。fail 状态表示，至少有一个哈希槽没有被绑定（说明有哈希槽没有被绑定到任意一个节点），或者在错误的状态（节点可以提供服务但是带有FAIL 标记），或者该节点无法联系到多数master节点。.
• cluster_slots_assigned: 已分配到集群节点的哈希槽数量（不是没有被绑定的数量）。16384个哈希槽全部被分配到集群节点是集群正常运行的必要条件.
• cluster_slots_ok: 哈希槽状态不是FAIL 和 PFAIL 的数量.
• cluster_slots_pfail: 哈希槽状态是 PFAIL的数量。只要哈希槽状态没有被升级到FAIL状态，这些哈希槽仍然可以被正常处理。PFAIL状态表示我们当前不能和节点进行交互，但这种状态只是临时的错误状态。
• cluster_slots_fail: 哈希槽状态是FAIL的数量。如果值不是0，那么集群节点将无法提供查询服务，除非cluster-require-full-coverage被设置为no .
• cluster_known_nodes: 集群中节点数量，包括处于握手状态还没有成为集群正式成员的节点.
• cluster_size: 至少包含一个哈希槽且能够提供服务的master节点数量.
• cluster_current_epoch: 集群本地Current Epoch变量的值。这个值在节点故障转移过程时有用，它总是递增和唯一的。
• cluster_my_epoch: 当前正在使用的节点的Config Epoch值. 这个是关联在本节点的版本值.
• cluster_stats_messages_sent: 通过node-to-node二进制总线发送的消息数量.
• cluster_stats_messages_received: 通过node-to-node二进制总线接收的消息数量.

（3）.查看集群信息：cluster nodes

CLUSTER NODES提供了当前连接节点所属集群的配置信息，信息格式和Redis集群在磁盘上存储使用的序列化格式完全一样（在磁盘存储信息的结尾还存储了一些额外信息）.

每行的组成结构如下:

<id> <ip:port> <flags> <master> <ping-sent> <pong-recv> <config-epoch> <link-state> <slot> <slot> ... <slot>

每项的含义如下:

1. id: 节点ID,是一个40字节的随机字符串，这个值在节点启动的时候创建，并且永远不会改变（除非使用CLUSTER RESET HARD命令）。
2. ip:port: 客户端与节点通信使用的地址.
3. flags: 逗号分割的标记位，可能的值有: myself, master, slave, fail?, fail, handshake, noaddr, noflags. 下一部分将详细介绍这些标记.
4. master: 如果节点是slave，并且已知master节点，则这里列出master节点ID,否则的话这里列出”-“。
5. ping-sent: 最近一次发送ping的时间，这个时间是一个unix毫秒时间戳，0代表没有发送过.
6. pong-recv: 最近一次收到pong的时间，使用unix时间戳表示.
7. config-epoch: 节点的epoch值（or of the current master if the node is a slave）。每当节点发生失败切换时，都会创建一个新的，独特的，递增的epoch。如果多个节点竞争同一个哈希槽时，epoch值更高的节点会抢夺到。
8. link-state: node-to-node集群总线使用的链接的状态，我们使用这个链接与集群中其他节点进行通信.值可以是 connected 和 disconnected.
9. slot: 哈希槽值或者一个哈希槽范围. 从第9个参数开始，后面最多可能有16384个 数(limit never reached)。代表当前节点可以提供服务的所有哈希槽值。如果只是一个值,那就是只有一个槽会被使用。如果是一个范围，这个值表示为起始槽-结束槽，节点将处理包括起始槽和结束槽在内的所有哈希槽。

注意：上述的master、slave的主从关系并不是固定，是随机直接建立的主从关系，上述操作后对应关系如下：

3.2. 三台master三台slave的redis集群配置实现读写操作

（1）.对6381新增两个key，操作如下：

（2）.上述操作为什么会报错，原因是什么，如何解决？

一定注意槽位的范围区间，因为目前6381这个master他的槽位介于0-6460，当创建k1的的时候，分配的槽位不在6381上就会出现异常报错，所以需要路由到位。

防止路由失效加参数-c并新增两个key，命令如下：

redis-cli -a 123456 -p 6381 -c

使用上述命令操作后，如下图，当前在6381里面创建k1，可以看到创建成功，并且是创建到了6385机器上

（3）.查看集群信息

（4）.查看某个key该属于对应的槽位值
语法如下：

CLUSTER KEYSLOT 键名称

执行后结果如下：

3.3. redis集群主从容错切换迁移案例

3.3.1.容错切换故障迁移

（1）.实现master主机6381和从机直接的切换，先停止主机6381

注意：

• 6381主机停了，对应的真实从机上位，
• 6381作为1号主机分配的从机以实际情况为准，具体是几号机器就是几号，我这里对应的6384，所以等一会6384会变为主机

（2）.再次查看集群信息

本次6381主机对应的6384从机，变为新的master主机，成功上位，如下图：

（3）随后再次重新启动6381原来的主机回来了，是否会上位？

恢复前6381由于宕机，查看集群中状态为fail，如下图：

重启6381，然后查看集群状态：

结结论：6381不会上位重新变成master，而是以从节点形式回归，主节点还是6384

3.3.2.集群并不保证数据一致性

redis集群不保证100%的数据强一致性，会有数据丢失情况，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入请求命令，例如，在某个主节点master宕机，从节点salve变为master的过程，就可能存在部分写入数据的丢失错误。参考官网如下https://redis.io/docs/reference/cluster-spec/#write-safety

3.3.3.手动故障转移后节点从属关系该如何调整？

上面故障转义后6381、6384主从对调了，和原始设计图不一样了，如何考虑回复成之前的情况，如何操作呢？

只需要重新登陆6381机器，执行 CLUSTER FAILOVER 命令即可恢复，如下图：

3.4. redis集群主从扩容案例

（1）.选择任意虚拟机新建6387、6388两个服务实例配置文件，在创建后启动

切记：创建后需要开放端口6387、16387、6388和16388才可以启动连接，否则会报错。

• 执行命令：vim  /myredis/cluster/redisCluster6387.conf，如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6387
logfile "/myredis/cluster/cluster6387.log"
pidfile /myredis/cluster6387.pid
dir /myredis/cluster
dbfilename dump6387.rdb
appendonly yes
appendfilename "appendonly6387.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6387.conf
cluster-node-timeout 5000

• 执行命令：vim  /myredis/cluster/redisCluster6388.conf，如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6388
logfile "/myredis/cluster/cluster6388.log"
pidfile /myredis/cluster6388.pid
dir /myredis/cluster
dbfilename dump6388.rdb
appendonly yes
appendfilename "appendonly6388.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6388.conf
cluster-node-timeout 5000

（2）.启动6387、6388两个新的节点实例，此时都是master

 查看6387：

 查看6388：

 

（3）.将新增的6387节点(空槽号)作为master节点加入原集群

将新增的6387作为master节点加入原有集群

redis-cli -a 密码 --cluster add-node 实际IP地址:6387 实际IP地址:6381

6387 就是将要作为master新增节点，6381 就是原来集群节点里面的领路人，；类似于6387让6381的带领着引荐给组织加入集群，最后执行的命令如下：

redis-cli -a 123456 --cluster add-node 192.168.42.132:6387 192.168.42.132:6381

 执行后如下图：

（4）.检查集群情况

语法格式如下：

redis-cli -a 密码 --cluster check 真实ip地址:6381

实际执行的命令：

redis-cli -a 123456 --cluster check 192.168.42.132:6381

如下图所示：

（5）.执行命令reshard 重新分派槽号

重新分派槽号，语法如下：

redis-cli -a 密码 --cluster reshard IP地址:端口号

实际执行的命令

redis-cli -a 123456 --cluster reshard 192.168.42.132:6381

执行后如下图：

（6）.再次检查集群情况

实际执行的命令：

redis-cli -a 123456 --cluster check 192.168.42.132:6381

 效果如下：

结论：

• 之所以6387是3个新的区间，是因为重新分配的成本太高，所以前3家各自匀出来一部分，从6381、6383、6385三个旧节点分别匀出1364个坑位给新节点6387使用即可。

为主节点6387分配从节点6388

（7）.给主节点6387分配从节点6388

 命令语法：

redis-cli -a 密码 --cluster add-node ip:新slave端口 ip:新master端口 --cluster-slave --cluster-master-id 新主机节点ID

执行的命令如下：

# --cluster-master-id 后面跟的是master主机6387的id： 48a2edaaf5d1305917182255adf3f28fbffa0f9e
redis-cli -a 123456 --cluster add-node 192.168.42.132:6388 192.168.42.132:6387 --cluster-slave --cluster-master-id 48a2edaaf5d1305917182255adf3f28fbffa0f9e

执行后如下图：

（8）.查看节点关系

使用命令查看节点情况：CLUSTER nodes

3.5. redis集群主从缩容案例

（1）.目录实现让6387和6388下线

这里模拟的缩容操作的案例。

（2）.在集群中将4号master的从节点6388删除

语法结构如下：

redis-cli -a 密码 --cluster del-node ip:从机端口 从机6388节点ID

执行的命令如下：

redis-cli -a 123456 --cluster del-node 192.168.42.132:6388 b034f05465d81c1cee1856b857858a7ec8c0f3ff

执行后如下图：

执行命令检查一下发现，6388被删除了，只剩下7台机器了

redis-cli -a 123456 --cluster check 192.168.42.132:6381

如下图：

（3）.将6387的槽号清空，重新分配，本例将清出来的槽号都给6381

执行命令：

redis-cli -a 123456 --cluster reshard 192.168.42.132:6381

执行后内容如下：

（4）.检查集群情况

执行命令：

redis-cli -a 123456 --cluster check 192.168.42.132:6381

4096个槽位都指给6381，它变成了8192个槽位，相当于全部都给6381了，不然要输入3次，而且你会发现这时候6381的slave变成了2个，其实是将6387变成了slave，让将他的主节点设置为了6381，如下图：

进入到6281，查看信息，发现6381作为了master，有两个从机6384和6387

（5）.从集群中删除6387

语法如下：

redis-cli -a 密码 --cluster del-node ip:端口 6387节点ID

执行的命令如下：

redis-cli -a 123456 --cluster del-node 192.168.42.132:6387 48a2edaaf5d1305917182255adf3f28fbffa0f9e

执行结果如下：

（6）.查看集群情况6387、6388被彻底删除

执行命令：

redis-cli -a 123456 --cluster check 192.168.42.132:6381

这里会发现6387已经被移除了，如下图：

五、集群常用操作命令和CRC16算法分析

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

如下图使用mget、mset操作多个键，会出现了错误，如

上述问题在于，不在同一个slot槽位下的键值无法使用mset、mget等多键操作，要解决这个问题，可以通过{}来定义同一个组的概念，使key中{}内相同内容的键值对放到一个slot槽位去，对照下图类似k1k2k3都映射为x，自然槽位一样，操作如下：

# 创建k100、k200、k300将其添加到group1组中，这样就会存储在同一个槽位
192.168.42.135:6385> mset k100{group1} v100 k200{group1} v200 k300{group1} v300
-> Redirected to slot [7859] located at 192.168.42.134:6383
OK
# 输出同一个组中的多个键值
192.168.42.134:6383> mget k100{group1} k200{group1} 
k300{group1}
1) "v100"
2) "v200"
3) "v300"
192.168.42.134:6383>

需要注意：

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

5.2.集群是否完整才能对外提供服务？

在集群配置文件中有参数：cluster-require-full-coverage，

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

5.3.如何得知该键应该存在哪个槽位上

使用命令：

CLUSTER KEYSLOT 键名称

执行后如下返回对应的槽位：

5.4.如何查询槽位是否被占用？

可以通过如下命令：

CLUSTER COUNTKEYSINSLOT 槽位数字编号

返回：

• 0该槽位没占用
• 1该槽位被占用

返回指定的 Redis Cluster 哈希槽中的键的数量。该命令仅查询本地数据集，因此联系未提供指定散列槽的节点将始终导致返回计数为零。