【大家好,我是爱干饭的猿,本文重点介绍Redis7 集群概述、作用、集群算法-分片-槽位slot、集群环境案例步骤、集群常用操作命令和CRC16算法。
后续会继续分享Redis7和其他重要知识点总结,如果喜欢这篇文章,点个赞👍,关注一下吧】
上一篇文章:《【Redis7】 Redis7 哨兵(重点:哨兵运行流程和选举原理)》
目录
3.6 Redis集群不保证强一致性,这意味着在特定的条件下,Redis集群可能会丢掉—些被系统收到的写入请求命令
集群:
编辑
🍔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: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
默认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的哈希槽位置
分享到此,感谢大家观看!!!
如果你喜欢这篇文章,请点赞加关注吧,或者如果你对文章有什么困惑,可以私信我。
🏓🏓🏓