【大家好，我是爱干饭的猿，本文重点介绍Redis7 集群概述、作用、集群算法-分片-槽位slot、集群环境案例步骤、集群常用操作命令和CRC16算法。

后续会继续分享Redis7和其他重要知识点总结，如果喜欢这篇文章，点个赞👍，关注一下吧】

上一篇文章：《【Redis7】 Redis7 哨兵（重点：哨兵运行流程和选举原理）》

目录

🍔1. 概述

🍔2. 作用

🍔3. 集群算法-分片-槽位slot

3.1 redis集群的槽位slot

​3.2 redis集群的分片

3.3 这样做的优势

3.4 slot槽位映射的3种解决方案

1. 哈希取余分区

​​2. 一致性哈希算法分区

3. 哈希槽分区

3.5 为什么redis集群的最大槽数是16384个?

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

🍔4. 集群环境案例步骤

4.1. 3主3从redis集群配置

4.2 3主3从redis集群读写，检验集群状态

4.3. 主从容错切换迁移案例

4.4. 主从扩容案例

4.5. 主从缩容案例

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

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

5.2 CRC16算法

5.3 集群常用操作命令

集群：

​

🍔1. 概述

• 由于数据量过大，单个Master复制集难以承担，因此需要对多个复制集进行集群，形成水平扩展每个复制集只负责存储整个数据集的一部分，这就是Redis的集群，其作用是提供在多个Redis节点间共享数据的程序集。
• Redis集群是一个提供在多个Redis节点间共享数据的程序集
• Redis集群可以支持多个Master

🍔2. 作用

• Redis集群支持多个Master，每个Master又可以挂载多个Slave
  • 读写分离
  • 支持海量数据的高可用
  • 支持海量数据的读写存储操作
• 由于Cluster自带Sentinel的故障转移机制，内置了高可用的支持，无需再去使用哨兵功能
• 客户端和Redis的节点连接，不再需要连接集群中所有节点，只需连接集群中的任意一个可用节点即可
• 槽位slot负责分配到各个物理服务节点，由对应的集群来负责维护节点、插槽和数据之间的关系

🍔3. 集群算法-分片-槽位slot

集群的密钥空间被分成16384个槽，有效地设置了16384个主节点的集群大小上限（但是，建议的最大节点大小约为1000个节点)。

集群中的每个主节点处理16384个哈希槽的一个子集。当没有集群重新配置正在进行时(即哈希槽从一个节点移动到另一个节点)，集群是稳定的。当集群稳定时，单个哈希槽将由单个节点提供服务(但是，服务节点可以有一个或多个副本，在网络分裂或故障的情况下替换它，并且可以用于扩展读取陈旧数据是可接受的操作)。

3.1 redis集群的槽位slot

​3.2 redis集群的分片

​

3.3 这样做的优势

​

3.4 slot槽位映射的3种解决方案

1. 哈希取余分区

​2. 一致性哈希算法分区

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

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

​

步骤2：服务器IP节点映射

​

步骤3：key 落到服务器的落键规则

​

优点：

1. 一致性哈希算法的容错性
​

2. 一致性哈希算法的扩展性
​

缺点：一致性哈希算法的数据倾斜问题

​小节：

为了在节点数目发生改变时尽可能少的迁移数据，将所有的存储节点排列在收尾相接的Hash环上，每个key在计算Hash后会顺时针找到临近的存储节点存放。 而当有节点加入或退出时仅影响该节点在Hash环上顺时针相邻的后续节点。

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

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

3. 哈希槽分区

a. 概念： 为解决一致性哈希算法的数据倾斜问题，哈希槽实质就是一个数组，数组[0,2^14 -1]形成hash slot空间。

b. 作用：解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据。

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

c. 多少个hash槽：

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

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

d. 哈希槽计算：

​

3.5 为什么redis集群的最大槽数是16384个?

(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的压缩率就很低。

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

🍔4. 集群环境案例步骤

4.1. 3主3从redis集群配置

1. 找3台真实虚拟机，各自新建文件夹cluster，放集群的配置文件

mkdir -p /myredis/cluster

2. 新建6个独立的redis实例服务 ，（一台虚拟机两个）也可以用6个服务器

​

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 111111
masterauth 111111cluster-enabled yes
cluster-config-file nodes-6381.conf
cluster-node-timeout 5000

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

注意，注意，注意自己的真实IP地址，-cluster-replicas 1 表示为每个master创建一个slave节点

redis-cli -a 111111 --cluster create --cluster-replicas 1 192.168.111.175:6381 192.168.111.175:6382 192.168.111.172:6383 192.168.111.172:6384 192.168.111.174:6385 192.168.111.174:6386

4.2 3主3从redis集群读写，检验集群状态

链接进入6381作为切入点，查看并检验集群状态

redis-cli -a 123456 -p 6381 -c    // -c表示集群 不加的话不是按照集群启动的，对于在别的机器上的key，会报错
cluster nodes       // 查看集群的主从关系
cluster info        // 查看集群信息     
info replication    // 查看主从
cluster keyslot k2  // 查看key的哈希槽位置

4.3. 主从容错切换迁移案例

例如：6384(主)-6381(从)

• 把6384停了，6381会成为master
  • 启动6384，6381还是master，并不会让位

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

  • 因为本质还是发送心跳包，需要一些时间判断是否down机，如果down机，对应的slave直接成为master

• 如果想要原先的master继续做master的话

  • CLUSTER FAILOVER   // 让谁上位 就在谁的端口号下执行这个命令

4.4. 主从扩容案例

• 新建6387、6388 两个服务实例配置文件+启动 (又加了个虚拟机 或者 直接在三个虚拟机里选一个)
• 启动87/88两个新的节点实例，此时他们自己都是master

​

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

  • redis-cli -a 123456  --cluster add-node 192.168.230.114:6387 192.168.238.111:6381

• 检查集群情况，6381

  • redis-cli -a 123456 --cluster check 192.168.238.111:6381

• 重新分配槽号

  • redis-cli -a 123456 --cluster reshard 192.168.238.111:6381

重新分配成本太高，所以前3家各自匀出来一部分，从6381/6383/6385三个旧节点分别匀出1364个坑位，注意本机这里经过调整所以我是需要从6381中分出4096即可

• 再次检查集群情况

  • redis-cli -a 123456 --cluster check 192.168.238.111:6381

• 为主节点6387分配从节点6388 –cluster-master-id 后跟的是6387的id

  • redis-cli -a 123456 --cluster add-node 192.168.238.114:6388 192.168.238.114:6387 --cluster-slave --cluster-master-id b861764cbba16a1b21536a3182349748e56f24cc
    

• 查看集群信息 

  • redis-cli -a 123456 --cluster check 192.168.238.111:6381

4.5. 主从缩容案例

让6388和6387下线

• 先获得6388的节点id（上图可获取），在集群中将6388删除

  • redis-cli -a 123456 --cluster del-node 192.168.238.114:6388 
    411144d66f28e876de5a6433689c8cbfab10686f
    

• 检查节点，只剩7台
• 将6387的槽号情况，重新分配，先全部都给6381

  • redis-cli -a 123456 --cluster reshard 192.168.238.111:6381

• 查看集群情况

​ 

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

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

查看配置配置文件中的 cluster-require-full-coverage

5.2 CRC16算法

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

5.3 集群常用操作命令

mset k1{x} v1 k2{x} v2 K3{x} v3
mget k1{x} k2{x} K3{x}CLUSTER COUNTKEYSINSLOT 槽位数字编号 // 1，该槽位被占用，0，该槽位没占用
CLUSTER KEYSLOT 键名称   // 该键应该存在哪个槽位上redis-cli -a 123456 -p 6381 -c    // -c表示集群 不加的话不是按照集群启动的，对于在别的机器上的key，会报错
cluster nodes       // 查看集群的主从关系
cluster info        // 查看集群信息     
info replication    // 查看主从
cluster keyslot k2  // 查看key的哈希槽位置

分享到此，感谢大家观看！！！

如果你喜欢这篇文章，请点赞加关注吧，或者如果你对文章有什么困惑，可以私信我。

🏓🏓🏓