Redis 主从复制、哨兵模式、集群模式

最新推荐文章于 2024-10-19 14:10:31 发布

舒适边缘

最新推荐文章于 2024-10-19 14:10:31 发布

阅读量780

点赞数 20

分类专栏： Redis 文章标签： redis java bootstrap

本文链接：https://blog.csdn.net/qq_34052481/article/details/134850539

版权

6 篇文章 0 订阅

订阅专栏

本文详细介绍了Redis的主从复制机制，包括其好处、流程和不同版本的数据同步策略；接着探讨了哨兵模式在故障转移中的应用，以及Sentinel如何判断主节点下线并进行故障转移；最后阐述了集群模式的特点和操作原理，包括选举过程。

摘要由CSDN通过智能技术生成

Redis主从的好处

Redis主从复制流程

Redis数据同步

完整重同步:主节点会fork出一个子进程进行RDB，主进程采用写时复制。子进程将RDB保存到自己磁盘后(也可以通过RDB文件流形式发送)，发送给子节点，子节点回放RDB文件进行同步,同时主节点将aof缓存区的命令发送给子节点。
部分重同步：部分重同步主节点会判断子节点发送的runid是否和自身相同，同步判断复制偏移量是否在复制积压缓存区，都满足则进行部分重同步，否则进行完整重同步

Redis各个版本同步指令

2.8之前使用SYNC命令进行完全冲同步，断线重连也需要完全重同步。
2.8~4.0使用PSYNC支持完全重同步和部分重同步，但是重启连和故障转移导致runid不同而进行完全重同步。
4.0之后引入PSYNC2，关闭服务前会记录runid和复制偏移量，同时使用两组replid,子节点也开启复制积压缓冲区。解决了重启和故障转移导致的完全重同步。

什么是哨兵

哨兵是Redis集群高可用的解决方案，由一个或者多个Sentinel实例组成的系统，会监控Redis主节点，以及主节点下的从节点。当主节点发生故障时，哨兵会在从节点选举一个作为新的主节点，进行故障转移，由新的主节点继续处理命令。
哨兵模式很好的解决了主从复制无法故障转移的缺点。但但redis数据量大时无法进行横向扩容。
实际开发中通过连接Sentinel来进行redis的操作以及读写分离

哨兵如何判断主节点下线

主观下线：Sentinel会每一秒钟发送PING命令给主节点，如果在一定时间内，返回无需回复，则判断该主节点掉线，进入主观下线状态
客户下线：主节点判断为主观下线后，Sentinel会向其他监视该节点的Sentinel发起询问该节点是否下线，如果其他Sentinel返回下线的计算合超过配置的数量，则判断该节点客户下线，会进行故障转移

哨兵如何进行故障转移

Sentinel选举

Sentinel选举采用Raft算法

每个节点都有机会成为领导者，当他们发现主节点客观下线时会，向其他Sentinel发送 Sentinel is-master-down-by-addr命令来让其投票给自己
其他Sentinel如果没有投票给其他的Sentinel，则投票，否则拒绝
当Sentinel的投票大于半数，且大于quornum时则选举为领导者，否则进入下次选举

Sentinel定时任务

redis集群模式的特点

操作key不在连接的redis节点上

当操作的key不在连接的redis节点上负责的槽位上，redis节点会快速返回moved错误，使得再次定位到key所属槽为redis节点进行操作。下次再请求会直接定位到相应的节点。
当redis增加节点时，槽位进行迁移，某部分key已经被移到新的节点上，那么请求时会先在老的节点判断是否存在，不存在则返回ask错误，到新的节点进行请求