发布时间:2022-09-24 15:30
Redis 的哨兵模式基本已经可以实现高可用,读写分离 ,但是在这种模式下每台 Redis 服务器都存储相同的数据,很浪费内存,所以在redis3.0上加入了 Cluster 集群模式,实现了 Redis 的分布式存储,也就是说每台 Redis 节点上存储不同的内容。
其结构特点:
1、所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
2、节点的fail是通过集群中超过半数的节点检测失效时才生效。
3、客户端与redis节点直连,不需要中间proxy层(负载均衡).客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
4、redis-cluster把所有的物理节点映射到[0-16383]slot(哈希槽,用来存储数据)上(不一定是平均分配),cluster 负责维护node<->slot<->value。
5、Redis集群预分好16384个哈希槽,当需要在 Redis 集群中放置一个 key-value 时,根据 CRC16(key) mod 16384的值,决定将一个key放到哪个桶中。redis集群是无中心化的,指定任一个节点ip都能访问整个集群。每个节点都能读写,但是写的时候会转换到对应哈希槽的节点上。
在一个虚拟机中,默认创建的集群有6个节点(分为三组,每组一主一从,)
集群内部划分为16384个数据分槽,分布在三个主redis(master上)中。
从redis中没有分槽,不会参与集群投票,也不会帮忙加快读取数据,仅仅作为主机的备份。三个主节点中,每个节点中不会存有重复数据,仅仅有自己的从机帮忙冗余。
实验:本次实验在一个虚拟机server1上创建集群总共6个节点。实际生产情况下,每台机器作为一个集群节点。
使用redis源码包create-cluster脚本创建集群(脚本中默认创建6个节点,可更改),每个master节点分配16384个哈希槽,用来存储。redis集群是无中心化的,指定任一个节点ip都能访问整个集群。
查看30001状态为master,对应slave为30004 ,-c 指定集群 -p指定端口
Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个master节点负责一部分哈希槽。此结构容易添加或者删除节点. 如果想添加新节点, 只需要从其他节点分部分哈希槽到新节点上. 如果想移除某节点,需要将此节点中的哈希槽移到其他节点上,然后将此节点从集群中移除. 哈希槽在节点中相互转移不会停止服务,因此添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
添加key值
Redis cluster集群的故障迁移
停掉30002做测试:自动将30002的slave30005 切换成master,并接管其哈希槽,只要16384个哈希槽不出错集群就能正常运行。当重新取启动30002时,其自动作为30005的slave。如果master挂掉,其slave成为master接管哈希槽集群可以正常工作,但当master的slave全都挂掉时,没有节点接受此哈希槽,导致集群不可用
再添加两个节点,只需要更改集群创建的脚本文件节点个数NODES:
添加30007节点为master:
--cluster集群 add-node添加节点到集群 添加30007为master 30001指向要添加进的集群
下面代码参数:从127.0.0.1:30008开始依次表示:节点30008; 指向集群30001; slave状态; 对应master30007的ID
此时master30007上没有哈希槽,迁移哈希槽给30007:all就是均衡的从其他3个节点上移3000个哈希槽到30007上
Redis 提供了不同级别的持久化方式:
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
- 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
- 你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
- 最重要的事情是了解RDB和AOF持久化方式的不同,让我们以RDB持久化方式开始