【五】redis主从同步与Redis Sentinel(哨兵)

主从同步

很多企业都没有使用到 Redis 的集群，但是至少都做了主从。有了主从，当 master 挂掉的时候，运维让从库过来接管，服务就可以继续，否则 master 需要经过数据恢复和重启的过程，这就可能会拖很长的时间，影响线上业务的持续服务。
Redis 通过主从同步功能实现主节点的多个副本。从节点可灵活地通过 slaveof 命令建立或断开同步流程。
如在副本节点127.0.0.1:666服务器上执行如下命令，

  SLAVEOF 127.0.0.6379

即为将127.0.0.6379设为自己的主节点（也可以通过在配置文件中增加replicaof 192.168.1.1 6379配置实现）

主从同步的过程：
主从同步有两个步骤:

同步：将从服务器的数据库状态更新成主服务器当前的数据库状态。从服务器对主服务的同步操作，需要通过 sync 命令来实现，以下是 sync 命令的执行步骤
- 从服务器向主服务器发送 sync 命令
- 收到 sync 命令后，主服务器执行 bgsave 命令，用来生成 rdb 文件，并在一个缓冲区中记录从现在开始执行的写命令。
- bgsave 执行完成后，将生成的 rdb 文件发送给从服务器，用来给从服务器更新数据
- 主服务器再将缓冲区记录的写命令发送给从服务器，从服务器执行完这些写命令后，此时的数据库状态便和主服务器一致了。
命令传播：经过同步后的主从暂时达成了数据的一致，但是主节点可能接收到新的命令，为了达成新的一致，就需要发送接收到的新命令到从节点，从服务器执行完之后，数据就又一致了

在 Redis 2.8 版本之前，进行主从复制时一定会顺序执行上述两个步骤，而从 2.8 开始则可能只需要执行命令传播即可。因为 sync 比较耗资源，需要尽量减少sync同步操作（但也无法完全不用），所以2.8之后对同步做了优化。
2.8优化后的主从同步：
主从同步实际分 2 种情况：

初次复制：从服务器第一次复制当前主服务器（PS：主服务器是有可能更换的，比如主服务器挂了，有一台从服务器接替成为了新的主服务器）
断线后重复制：处于命令传播阶段的主从服务器，因为网络问题而中断复制，从服务器通过自动重连，重新连接上主服务器并继续复制。

在断线后重复制的情况下，在 2.8 版本之前，会再次执行同步（sync 命令）和命令传播。

如果说，在断线期间，主服务器（已有上万键值对）只执行了几个写命令，为了让从服务器弥补这几个命令，却要重新执行 sync 来生成新的 rdb 文件，这也是非常低效的。

为了解决这个问题，2.8 开始就使用 psync 命令来代替 sync 命令去执行同步操作。
psync 具有完整重同步和部分重同步两种模式：
完整重同步：用于初次复制情况，执行过程同 sync，在这不赘述了。
部分重同步：用于断线后重复制情况，如果满足一定条件，主服务器只需要将断线期间执行的写命令发送给从服务器即可。
因此很明显，当主从同步出现断线后重复制的情况，psync 的部分重同步模式可以解决 sync 的低效情况。

上面的介绍中，出现了「满足一定条件」，那又是鬼什么条件呢？—— 其实就是一个偏移量的比较，具体可以继续往下看。

部分重同步的实现
部分重同步功能由以下 3 部分组成：

主从服务器的复制偏移量
主服务器的复制积压缓冲区
服务器的运行 id（run id）

1 复制偏移量
执行复制的主从服务器都会分别维护各自的复制偏移量：

主服务器每次向从服务器传播 n 个字节数据时，都会将自己的复制偏移量加 n。
从服务器接受主服务器传来的数据时，也会将自己的复制偏移量加 n
举个例子：

若当前主服务器的复制偏移量为 10000，此时向从服务器传播 30 个字节数据，结束后复制偏移量为 10030。

这时，从服务器还没接收这 30 个字节数据就断线了，然后重新连接上之后，该从服务器的复制偏移量依旧为 10000，说明主从数据不一致，此时会向主服务器发送 psync 命令。

那么主服务器应该对从服务器执行完整重同步还是部分重同步呢？如果执行部分重同步的话，主服务器又如何知道同步哪些数据给从服务器呢？

以下答案都和复制积压缓冲区有关

2 复制积压缓冲区
首先，复制积压缓冲区是一个固定长度，先进先出的队列，默认 1MB。

当主服务器进行命令传播时，不仅会将命令发送给从服务器，还会发送给这个缓冲区。

因此复制积压缓冲区的构造是这样的：

当从服务器向主服务器发送 psync 命令时，还需要将自己的复制偏移量带上，主服务器就可以通过这个复制偏移量和复制积压缓冲区的偏移量进行对比。

若复制积压缓冲区存在从服务器的复制偏移量 + 1 后的数据，则进行部分重同步，否则进行完整重同步。

3 run id
运行 id 是在进行初次复制时，主服务器将会将自己的运行 id 发送给从服务器，让其保存起来。
当从服务器断线重连后，从服务器会将这个运行 id 发送给刚连接上的主服务器。
若当前服务器的运行 id 与之相同，说明从服务器断线前复制的服务器就是当前服务器，主服务器可以尝试执行部分同步；若不同则说明从服务器断线前复制的服务器不是当前服务器，主服务器直接执行完整重同步。

4.心跳检测
刚才提到，主从同步有同步和命令传播 2 个步骤。

当完成了同步之后，主从服务器就会进入命令传播阶段，此时从服务器会以每秒 1 次的频率，向主服务器发送命令：

REPLCONF ACK <replication_offset>

其中 replication_offset 是从服务器当前的复制偏移量

发送这个命令主要有三个作用：

检测主从服务器的网络状态
辅助实现 min-slaves 选项
检测命令丢失（若丢失，主服务器会将丢失的写命令重新发给从服务器）

总结：
同步复制分为：全量复制和部分增量复制，主从节点之间维护心跳和偏移量检查机制，保证主从节点通信正常和数据一致。
Redis 为了保证高性能复制过程是异步的，写命令处理完后直接返回给客户端，不等待从节点复制完成。因此从节点数据集会有延迟情况。即当使用从节点用于读写分离时会存在数据延迟、过期数据、从节点可用性等问题，需要根据自身业务提前作出规避。

注意：在运维过程中，主节点存在多个从节点或者一台机器上部署大量主节点的情况下，会有复制风暴的风险。

Redis Sentinel(哨兵)

主从复制是 Redis 分布式的基础，Redis 的高可用离开了主从复制将无从进行。后面的我们会讲到 Redis 的集群模式，集群模式都依赖于本节所讲的主从复制。

不过复制功能也不是必须的，如果你将 Redis 只用来做缓存，也就无需要从库做备份，挂掉了重新启动一下就行。但是只要你使用了 Redis 的持久化功能，就必须认真对待主从复制，它是系统数据安全的基础保障。

举例：如果主节点凌晨 3 点突发宕机怎么办?就坐等运维从床上爬起来，然后手工进行从主切换，再通知所有的程序把地址统统改一遍重新上线么?毫无疑问，这样的人工运维效率太低，事故发生时估计得至少 1 个小时才能缓过来。

Sentinel 负责持续监控主从节点的健康，当主节点挂掉时，自动选择一个最优的从节点切换为主节点。客户端来连接集群时，会首先连接 sentinel，通过 sentinel 来查询主节点的地址，然后再去连接主节点进行数据交互。当主节点发生故障时，客户端会重新向 sentinel 要地址，sentinel 会将最新的主节点地址告诉客户端。如此应用程序将无需重启即可自动完成节点切换。如图：

消息丢失

Redis 主从采用异步复制，意味着当主节点挂掉时，从节点可能没有收到全部的同步消息，这部分未同步的消息就丢失了。如果主从延迟特别大，那么丢失的数据就可能会特别多。Sentinel 无法保证消息完全不丢失，但是也尽可能保证消息少丢失。它有两个选项可以限制主从延迟过大：

min-slaves-to-write 1
min-slaves-max-lag 10

第一个参数表示主节点必须至少有一个从节点在进行正常复制，否则就停止对外写服务，丧失可用性。

何为正常复制，何为异常复制?这个就是由第二个参数控制的，它的单位是秒，表示如果 10s 没有收到从节点的反馈，就意味着从节点同步不正常，要么网络断开了，要么一直没有给反馈。

Redis 最终一致

Redis 的主从数据是异步同步的，所以分布式的 Redis 系统并不满足「一致性」要求。当客户端在 Redis 的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节点依旧可以正常对外提供修改服务，所以 Redis 满足「可用性」。

Redis 保证「最终一致性」，从节点会努力追赶主节点，最终从节点的状态会和主节点的状态将保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，一旦网络恢复，从节点会采用多种策略努力追赶上落后的数据，继续尽力保持和主节点一致

文章参考：https://mp.weixin.qq.com/s/-3fcK4WspGk6SEsaVrdx8A
https://zhuanlan.zhihu.com/p/55532249