【IT老齐018】Redis高可用Sentinel架构方案

【IT老齐018】Redis高可用Sentinel架构方案

主从复制

master主要负责写入，slave负责读取。有读写分离的功能

主从同步原理

1. slave执行命令向master建立连接
2. master执行bgsave（后台存储），生成rdb快照（redis备份方式，data以二进制方式保存在本地），发送到slave上
3. slave获取快照后读取，对data还原，保证初始化数据一致
4. master接受命令发送到salve，salve执行保证后续数据一致

缺点：master挂掉，redis集群瘫痪。

哨兵模式

• 建立sentinel集群，有一个leader角色
• 一般需要6个节点，3个sentinel，3个主从。
• sentinel安装在节点上，根据配置信息监听redis的健康状态。（每个sentinel 1次/秒频率向master，salve及其他sentinel实例发送ping命令）

故障发现

主动下线：实例最后一次有效回复时间超时（不靠谱，存在网络问题误判）
客观下线：多个sentinel ping不通（多个=总数除以2+1）

故障转移

选举master服务器

• 剔除主观下线、已断线、或者最后一次回复PING命令的时间大于五秒钟的Slave
• 剔除与失效主服务器连接断开的时长超过down-after选项指定的时长十倍的Slave
• 按同步数据的偏移量选出数据最完整的Slave
• 如果偏称量相同，选中ID最小的Slave

数据同步

1. 向被选中的从服务器发送SLAVEOF NO ONE命令，让它转变为主服务器。
2. 通过发布与订阅功能，将更新后的配置传播给所有其他Sentinel，其他Sentinel对它们自2的配置进行更新。
3. 向所有Slave下达SLAVEOF命令，指向新的主
4. redis-slave向master重新建立连接，重放rdb保持数据同步
5. 在上述转移过程中，伴随着Redis本地配置文件的自动重写，这样即使是实例重启配置也不会丢失
6. 原有的master在恢复后降级为slave与新master全量同步

Sentinel高可用

高可用条件

1. sentinel自动故障迁移使用raft算法来选举领头(leader) sentinel
2. 超过半数投票选出leader, sentinel Leader用于下达故障转移的指令
3. 如果某个Leader挂了，则使用Raft从剩余的Sentinel中选出leader

哨兵互相感知方式

Sentinel的信息在redis的master进行注册，master持有Sentinel的信息。

拓展

• 向主服务器写入文件但是从服务器没有读取到或者延迟比较大怎么处理呢
  • 对于Redis 后才采用bgsave并发送，如果从写入失败或者网络传输timeout，Slave端会报错，需要重新做slaveof进行全量同步。这时sentinel会监听到并重试。
  • 主从服务器数据同步有两种方式，一种是全量同步，一种是半同步，具体采用哪种同步方式？需要根据三个指标：主服务器id，偏移量，积压缓冲区。当主从服务器同步时发生超时或者网络故障导致同步失败，从服务器重新上线后，会把自己保存的主服务器id和偏移量发给主服务器，主服务器首先对比从服务器发来的id是否与自己的相同，如果不同，进行全量同步，如果相同，再根据从服务器发来的偏移量和自己的积压缓冲区中的偏移量对比，如果积压缓冲区里有偏移量之后的数据，则进行半量同步，否则，进行全量同步。另外，全量同步会极大增加主服务器的负担，导致缓存功能下降，设置合理的积压缓冲区大小很有必要！