Redis主从复制与哨兵（原理篇）

概述

当单机Redis已经无法支持过多的请求时就该考虑如何进行扩展了，Redis提供了主从复制，哨兵机制。

主从复制

特点

• 主服务器负责处理写请求
• 从服务器负责处理读请求
• 主从服务器的数据保持一致

具体配置方法在这篇博客里：传送门~

原理

原理这主要介绍的是主从复制的关键——复制

---

复制分为两个部分：

1. 同步：将主服务器的数据全部同步到从服务器中
2. 命令传播： 当主服务器中执行写命令时，将写命令传输一份到从服务器执行，保证一致性。

同步

同步又可以分成两个情况：

1. 首次同步：这个从服务器还没有复制过任何主服务器，或从服务器此次复制的主服务器和上一次的不同。
2. 部分同步：处于命令传播阶段的从服务器出现了问题导致了中断，在恢复正常后自动重连进行的同步。

完整同步

步骤	主服务器操作	从服务器操作
1	建立连接	建立连接
2	接收同步命令	发送同步命令
3	执行bgsave操作，同时启动缓冲区记录备份快照过程中的写命令	根据配置的选项决定使用现有的数据处理客户端请求，或者向发送请求的客户端返回错误信息
4	bgsave执行完毕，开始向从服务器发送快照文件，同时缓冲区继续记录写命令	丢弃所有原数据，接收主服务器传来的快照文件，并载入它
5	快照文件发送完毕后，向从服务器发送缓冲区中的命令	载入快照后开始正常接收并执行主服务器发送的命令
6	缓冲区中的命令发送完毕，从现在开始每执行一条写命令都会向从服务发送相同的写命令	接收主服务器器缓冲区的命令并执行，执行完毕后，开始正常接收并执行主服务器发送的写命令

部分同步

在Redis 2.8之前如果出现了断线重连，哪怕只是丢失了几条命令也需要进行完整重同步。在2.8以后实现了部分重同步，只需要同步丢失部分的数据即可。

• 主从服务器的复制偏移量：主从服务器上都会维护一个变量叫复制偏移量，主服务器每发送出N条命令它的偏移量就会+N，从服务器每接收到M条命令它的偏移量也会+M。只需要对比偏移量就可以判断主从服务器是否一致！
  （图片来源于：https://segmentfault.com/a/1190000017170690）

- 复制积压缓冲区： 主服务器进行命令传播时还会将命令存入复制积压缓冲区（缓冲区大小可配置），如果缓冲区中存在丢失的数据，那么执行部分重同步，否则执行完整重同步。

• 服务器ID： 服务器ID是用来判断请求同步的从服务器是新来的或者是断线重连的，新服务器则走完整重同步，断线重连则判断复制积压缓冲区中是否有丢失的数据。

命令传播

• 完成了同步后，主从服务器 进入了命令传播阶段，主服务器每执行一条写命令都会同步给从服务器，从而保证一致性。
• 从服务器也会每秒一次的频率向服务器发送命令REPLCONF ACK其中包含从服务器的复制偏移量，用于检测主从服务器的网络状态和检测命令丢失。

哨兵

概述

Redis的哨兵模式用于为Redis实现高可用，在主从分离的模型中，如果主服务器宕机了，那么哨兵将会选举主服务器下的一台从服务器升级为主服务器提供服务。

当master宕机后：

什么是Sentinel

我们在Docker中配置Sentinel并不需要重新下载镜像，而是使用Redis的就可以，事实上Sentinel的本质就是运行在特殊模式下的Redis服务器，但是它启动时并不会读取AOF和RDB文件，因为它本身并不提供数据库服务。

原理

1. Sentinel初始化： 根据配置文件中配置的master信息，初始化Sentinel监控的主服务列表。

2. 获得master节点详细信息： Sentinel向每一台master发送INFO命令来获取master节点中的详细信息，包含名称，id，slave信息等。
   （图片素材来自：https://segmentfault.com/a/1190000017250990#articleHeader2）
   

3. 判断服务器是否下线：

• 主观下线： Sentinel会每隔一秒向主从服务器以及其他Sentinel发送Ping命令，如果超过指定的时间（ own-after-milliseconds）没有回复，那么该Sentinel就会认为该服务器下线。
• 客观下线： 当一个Sentinel判断一个服务器下线后，它为了确定是否真的下线，会向其他Sentinel确认是否真的下线了，如果足够多的Sentinel认为该服务器下线了，那么就判断该服务器客观下线了，如果没有足够的Sentinel同意该服务器是下线的，那么Master的客观下线状态会被移除。
• 定时任务：

1. 每10秒Sentinel向所有master和slave发送info命令。（发现slave节点，确认主从关系）
2. 若master被判定下线后，sentinel向master下的slave发送info命令的频率变为1秒1此。
3. 每1秒每个sentinel对其他的sentinel和master和slave发送ping命令，进行心跳检测，检测是否下线。

4. 故障转移：

• 选举领头Sentinel： 当一个master被认为客观下线后，监视此master的sentinel会进行协商，选出一个领头sentinel进行故障转移。

选举策略：

1. 所有的sentinel都有公平的被选举为领头的资格。
2. 一旦某个sentinel被选为领头后，将不能更改，并且后序申请领头的请求都将会被拒绝。
3. sentinel在发现服务器可观下线后都会申请领头，简单说就是先到先得。

• 主从切换： 选出的领头sentinel会对已经下线的master执行转移操作：

1. 从已下线的master中挑选出一个slave。
2. 设置其他slave的新mater为刚刚挑选出来的slave。
3. 当原先下线的master出重新连接时，让它成为新的mater的slave。