【大家好，我是爱干饭的猿，本文重点介绍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 111111
cluster-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:63814.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
默认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 ，这样的话你挂了的那个小集群是不行了，但是其他的小集群仍然可以对外提供服务。 |
5.2 CRC16算法
Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽
5.3 集群常用操作命令
不在同一个slot槽位下的键值无法使用mset、mget等多键操作 |
可以通过{}来定义同一个组的概念，使key中{}内相同内容的键值对放到一个slot槽位去，对照下图类似k1k2k3都映射为x，自然槽位一样 |
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的哈希槽位置
分享到此，感谢大家观看！！！
如果你喜欢这篇文章，请点赞加关注吧，或者如果你对文章有什么困惑，可以私信我。
