Redis-Sentinel总结

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/redis/Redis-Sentinel-Summary.html

1.Redis主从架构

1. 主节点负责写入操作
2. 从节点可以提供读取操作(可配置,有延迟,高一致性的场景下需要注意)

2.Redis主从复制流程

1. Redis Slave 与Master建立连接
2. Master执行bgsave生成rdb快照文件
3. Master发送rdb快照文件给到Slave
4. Slave接收到rdb快照文件后,清空自己的数据,然后加载rdb快照文件
5. 同时,Master会继续将新的写操作同步给Slave(这里用了老版本用的环形结构,高并发情况下可能会丢数据,新版本用的无盘复制不会有这个问题)
6. Slave加载完rdb快照文件后,开始接收Master的写操作,完成同步
7. 之后Slave会周期性的向Master发送sync命令,Master接收到sync命令后,会将新的写操作同步给Slave,保证数据的一致性

3.Redis-Sentinel高可用集群

每个Sentinel节点每秒钟会向所有Redis节点以及所有Sentinel节点发送ping命令(实际上是info命令),来确认节点是否正常工作

3.1 Redis故障发现&故障转移

故障发现

1. 如果Sentinel主节点发现Master节点挂了(Ping命令响应超时,对应配置为own-after-millisecond),那么Sentinel会将这个节点标记为主观下线
2. Sentinel主节点通知Sentinel从节点们ping这个Master节点,如果有足够多Sentinel节点认为Master节点挂了(可配置,一般配置为过半,也就是2个节点),那么Sentinel会将这个节点标记为客观下线,即『真下线』

故障转移

Sentinel主节点会剔除无效节点(最近一次ping超时)，并且选取一个偏移量最新的Redis Slave节点作为新的Master节点（偏移量一致会根据节点id，选最小的）

1. Sentinel主节点下发slave of no one命令给新的Master节点,让它升级为Master节点
2. Sentinel从节点订阅原有的Redis从节点信息发现该节点已经变成了Master节点,于是将自己的Master节点信息更新为新的Master节点,同时把原来的主节点信息给剔除掉
3. Sentinel主节点向其他所有的Redis从节点下达slave of命令,让它们成为新的Master节点的从节点
4. 新的从节点会重新执行一次主从复制流程,从新的Master节点同步数据
5. 故障转移完成

PS.原有的Master在故障恢复后会变成新的Master的从节点,启动后执行主从复制流程,与新Master保持数据一致

4. Sentinel集群的高可用

Sentinel相互感知发现

1. 每个Sentinel节点都会在Redis注册自己的信息

Sentinel的故障发现与选举

基于Raft算法,大意是说:

1. 主节点与从节点之间维持心跳(心跳的时候还会顺带带上新的日志信息)
2. 从节点如果一定时间内收不到主节点的心跳信息,自己就会发起选举选自己为主节点
3. 其他节点会根据选举周期、日志偏移量确定是否能让他升主节点
4. 就这样🤷

raft算法详细可以参考: 这个up主的视频