【随笔记】redis主从及哨兵模式间解

redis主从及哨兵模式间解

redis主从模式

工作原理

一： master配置了一个slave，这个slave无论是否为第一次与master建立连接，它都会发送sync命令，去master同步数据。

二： master收到来自slave的sync命令后，会在后台进行数据的持久化操作，通过bgsave生成最新的rdb全量数据快照文件；

三： 在生成全量的rdb快照文件过程中，master会继续接收来自客户端的请求，它会把这些可能存在的修改数据集的请求缓存在内存中。当上一步持久化数据完毕后，master会把这份全量数据的rdb文件发送给slave，slave收到数据后加载到内存中，master再将缓存中的变化量数据发送给slave。

四： 如果在这个过程中，master与slave之间出现连接断开，slave在后续自动重连到master，如果多个slave同时连接master，master生成的数据快照是可以生成一次，并发送给所有slave的。另外出现断链后，会可以支持部分数据同步。

哨兵模式

哨兵模式为特殊的redis服务，作为监控redis实例节点，哨兵架构下的client从哨兵中得到redis的主节点，后续可以一直访问该节点，不需要每次都去sentinel代理访问redis主节点。

如果redis的主节点发生变化，哨兵会将新的主节点推送给client。

redis哨兵模式底层原理

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master. 　　每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown). ​ 若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置. 　　虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel). 哨兵(sentinel) 的一些设计思路和zookeeper非常类似