1、特点
集群由多个node节点组成,redis数据分布在这些节点中,在集群中分为主节点和从节点,一个主对应一个从,所有组的主从形成一个集群,每组的数据是独立的,并且集群自带哨兵模式
2、工作原理
集群模式中,主从一一对应,数据写入和读取与主从模式一样,主负责写,从只能读;集群模式自带哨兵模式,可以自动实现故障切换,但在故障切换完成之前,整个集群不可用,切换完毕后,集群立刻恢复
3、集群模式按照数据分片
(1)数据分片:集群核心功能。每个主都可以对外提供读、写功能,但数据是一一对应写入主的对应从节点,所以在集群模式中,不能保证数据的完整性
(2)高可用:集群主要目的
4、数据分片的实现过程
redis的集群引入hash槽的概念
redis集群中共有16384个哈希槽位(0-16383)
如何分配hash槽位?
根据集群中的主从节点数分配hash槽位,每个主从节点只负责一部分的hash槽位。每次读写都涉及hash槽位,key通过CRC16的校验机制,对16384取余,余数值决定数据放入哪个hash槽位,通过余数值找到对应槽位找到所在节点,直接跳转到这个节点进行存储操作【每个节点的hash槽位值是连续的。若出现不连续的hash槽位或hash槽位没有被全部分配,集群会报错】
hash槽位的原理结构图:
故障切换过程中为什么会提示集群不可用?hash槽位无人接手
主宕机后,主节点原来负责的hash槽位将会不可用,此时需要从节点代替主节点继续负责原有的hash槽位,保证集群正常工作。故障切换过程中,会提示集群不可用;切换完成后,集群恢复,继续工作
5、redis-cluster集群实验
实验目的:实现集群高可用
实验条件:
IP地址 | 初始服务器 | 组件 |
20.0.0.14 | 创建集群,自动随机分配一一对应的主从服务器 | redis服务 |
20.0.0.24 | redis服务 | |
20.0.0.34 | redis服务 | |
20.0.0.44 | redis服务 | |
20.0.0.54 | redis服务 | |
20.0.0.64 | redis服务 |
实验步骤:
(1)修改配置文件【所有服务器】
vim /etc/redis/6379.conf
(2)、创建集群
redis-cli -h 20.0.0.14 --cluster create 20.0.0.14:6379 20.0.0.24:6379 20.0.0.34:6379 20.0.0.44:6379 20.0.0.54:6379 20.0.0.64:6379 --cluster-replicas 1
-cluster- replicas 1 规定一个主只有一个从【主从是随机分配的】
集群模式中,集群模式不能切换库,只能选择默认库——0库
(3)、查看hash槽位CLUSTER nodes
此时的主、从服务器
主 | 从 |
20.0.0.14——redis1 | 20.0.0.54——redis5 |
20.0.0.24——redis2 | 20.0.0.64——redis6 |
20.0.0.34——redis3 | 20.0.0.44——redis4 |
(4)测试
在任意一个主中创建键值对
主20.0.0.14——redis1 从20.0.0.54——redis5
①验证从节点能不能读。不能
此处error不是报错,表明客户端尝试读取键值对test1,但是实际槽位在4768,因此集群要求客户端移动到4768槽位所在的主机节点获取数据
②验证从节点能不能写。不能
③验证分配hash槽位后,不在相应的hash槽位上的主节点能不能写。不能,只能到指定节点上操作
主
从
(5)模拟故障
任意一台主服务器故障
主20.0.0.34——redis3故障,从20.0.0.44——redis4成为新主
(6)恢复故障
恢复原主20.0.0.34——redis3
(7)、监控redis实时工作日志,检测主从节点之间的心跳线
主
从