Redis主从复制架构和Sentinel哨兵机制

最新推荐文章于 2022-07-22 18:44:30 发布

Kill Console

最新推荐文章于 2022-07-22 18:44:30 发布

阅读量172

点赞数

本文链接：https://blog.csdn.net/gr32442187do/article/details/103630370

版权

一、redis主从复制原理

redis主从同步策略：slave刚加入集群会触发一次全量同步（全量复制）。全量同步之后，进行增量复制。slave优先是增量同步，如果增量同步失败会尝试从master节点进行全量复制。
全量复制：slave初始化阶段

如上图

slave服务器首先连接master节点，发送SYNC命令。
master节点收到SYNC命令开始指令BGSAVE（延迟写，读正常）命令生成RDB（快照）文件，在此期间master的写请求会被缓存。
RDB生成，master会将该RDB发送给所有的slave。
slave收到RDB文件会抛弃之前的旧数据，然后载入新的RDB。
master完成RDB发送，会执行之前阻塞的写命令，并将这些命令同步到slave节点。（增量复制）
以上步骤完成后master和slave开始正常工作。

值得注意的是，全量复制对主从都是非阻塞的，是异步复制。

增量复制：master每次的写命令会同步到slave，slave收到命令执行对应命令。

断点续传：在步骤3步骤中，master发送给slave的文件过程中，网络故障了，重连后，master仅会复制给slave缺少的部分（会记录offset偏移量）。

master node 会在内存中维护一个 backlog，master 和 slave 都会保存一个 replica offset 还有一个 master run id，offset 就是保存在 backlog 中的。如果 master 和 slave 网络连接断掉了，slave 会让 master 从上次 replica offset 开始继续复制，如果没有找到对应的 offset，那么就会执行一次 resynchronization。

主从复制中的内存淘汰策略：slave不会主动淘汰过期key，master处理掉的过期key，会向slave发送一个del命令，同步淘汰的数据。

心跳数据：master 默认每隔 10秒发送一次 heartbeat，slave node 每隔 1秒发送一个 heartbeat。

注意，如果采用了主从架构，那么建议必须开启 master node 的持久化，不建议用 slave node 作为 master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了。
另外，master 的各种备份方案，也需要做。万一本地的所有文件丢失了，从备份中挑选一份 rdb 去恢复 master，这样才能确保启动的时候，是有数据的，即使采用了高可用机制，slave node 可以自动接管 master node，但也可能 sentinel 还没检测到 master failure，master node 就自动重启了，还是可能导致上面所有的 slave node 数据被清空。

二、哨兵机制

哨兵之前的主从架构是需要在各自的配置文件中手动配置自己的master或者slave节点。（方便理解后面的Configuration传播）
假如采用了redis的主从方案，那么当master节点宕机，主备切换的过程是需要运维人员手动完成的，人工的故障转移是十分的耗时而且对运维人员的要求是极高的。
所以就有了基于redis哨兵（Sentinel）机制搭建的高可用架构。

1，sentinel

中文哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：

集群监控：负责监控 redis master 和 slave 进程是否正常工作。
消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。
即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

2，核心知识

哨兵至少需要 3 个实例，来保证自己的健壮性。
哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

3，故障转移

sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机
odown 是客观宕机，如果 quorum 数量的哨兵都觉得一个 master 宕机了，那么就是客观宕机

sdown 达成的条件很简单，如果一个哨兵 ping 一个 master，超过了 is-master-down-after-milliseconds 指定的毫秒数之后，就主观认为 master 宕机了；如果一个哨兵在指定时间内，收到了 quorum 数量的其它哨兵也认为那个 master 是 sdown 的，那么就认为是 odown 了。