Redis 实战 —— Redis 主从复制原理

1. Redis 主从复制

1.1 主从复制

和 mysql 主从复制的原因一样，Redis 虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis 支持主从复制。Redis 的主从结构可以采用一主多从或者级联结构，下图为级联结构：

Redis 支持复制的功能，以实现当一台服务器的数据更新后，自动将新的数据同步到其他数据库。

Redis 复制实现中，把数据库分为 主数据库（master）和 从数据库（slave）。master 可以进行读写操作，slave 一般是只读的。当 master 数据变化的时候自动将数据同步给 slave。

1.2 Redis 主从复制的好处

1. 可以实现读写分离
2. 利于在主数据库奔溃时的数据恢复

1.3 主从复制的配置

master 节点不需要进行配置，slave 需要在 redis.conf中配置：

slaveof 主数据库ip 6379

如果 master 设置了密码，需要添加配置

masterauth 密码

1.4 主从切换的操作命令

1. info replication：查看主从节点的相关信息。
2. slaveof：切换主节点。
3. slaveof no one：切换当前数据库为 master。

2. Redis 主从复制的原理

Redis 主从复制可以根据是否是全量分为全量同步和增量同步

2.1 全量同步

Redis 全量复制一遍发生在 slave 初始化阶段，这时 slave 需要将 master 上的所有数据都复制一份。具体步骤如下：

1. slave 连接 master，发送 SYNC 命令；

2. master 接收到 SYNC 命名后，开始执行 BGSAVE命令生成 RDB快照文件并使用缓冲区记录此后执行的所有写命令；

3. master BGSAVE执行完后，向所有 slave 发送快照文件，并在发送期间继续记录被执行的写命令；

4. slave 收到快照文件后丢弃所有旧数据，载入收到的快照；

5. master 快照发送完毕后开始向 slave 发送缓冲区中的写命令；

6. slave 完成对快照的载入，开始接收命令请求，并执行来自 master 缓冲区的写命令；

完成上面几个步骤后就完成了 slave 数据初始化的所有操作，slave 此时可以接收来自用户的读请求。

2.2 增量同步

Redis 增量复制是指 slave 初始化后开始正常工作时 master 发生的写操作同步到 slave 的过程。

增量复制的过程主要是 master 每执行一个写命令就会向 slave 发送相同的写命令，slave 接收并执行收到的写命令。

2.3 Redis 主从同步策略

主从刚刚连接的时候，进行全量同步。全量同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求 slave 进行全量同步。

注意：

如果多个 slave 断线，需要重启的时候，因为需要 slave 启动就会发送 sync 请求 和主机全量同步。当多个同时出现的时候可能会导致 master io 剧增宕机。

关于 slave 服务器上过期键的处理，由 master 服务器负责键的过期删除处理，然后将相关删除命令已数据同步的方式同步给 slave 服务器，slave 服务器根据删除命令删除本地的 key。

2.4 无盘复制

在上面的全量同步过程中，master 会将数据保存在 rdb 文件中然后发送给 slave 服务器，但是如果 master 上的磁盘空间有限怎么办呢？

那么此时全部同步对于 master 来说将是一份十分有压力的操作了。此时可以通过无盘复制来达到目的，由 master 直接开启一个 socket 将 rdb 文件发送给 slave 服务器。（无盘复制一般应用在磁盘空间有限但是网
络状态良好的情况下）

3. master 不能持久化时主从复制的安全问题

在进行主从复制设置时，强烈建议在主服务器上开启持久化，当不能这么做时，比如考虑到延迟的问题，应该将实例配置为避免自动重启。

为什么不持久化的主服务器自动重启非常危险呢？

为了更好的理解这个问题，看下面这个失败的例子，其中主服务器和从服务器中数据库都被删除了。

1. 设置 节点A 为主服务器，关闭持久化，节点B和C 从节点A复制数据。

2. 这时出现了一个崩溃，但 Redis 具有自动重启系统，重启了进程，因为关闭了持久化，节点重启后只有一个空的数据集。

3. 节点B和C从节点A进行复制，现在节点A是空的，所以节点 B和C 上的复制数据也会被删除。

当在高可用系统中使用 Redis Sentinel，关闭了主服务器的持久化，并且允许自动重启，这种情况是很危险的。

比如主服务器可能在很短的时间就完成了重启，以至于Sentinel都无法检测到这次失败，那么上面说的这种失败的情况就发生了。

如果数据比较重要，并且在使用主从复制时关闭了主服务器持久化功能的场景中，都应该禁止实例自动重启。

4. 限制有 N 个以上从服务器才允许写入

从 Redis 2.8 版本开始，可以配置主服务器连接 N 个以上从服务器才允许对主服务器进行写操作。但是，因为Redis 使用的是异步主从复制，没办法确保从服务器确实收到了要写入的数据，所以还是有一定的数据丢失的可能性。

这一特性的工作原理如下：

1. 从服务器每秒钟ping一次主服务器，确认处理的复制流数量。
2. 主服务器记住每个从服务器最近一次ping的时间。
3. 用户可以配置最少要有 N 个服务器有小于 M 秒的确认延迟。
4. 如果有 N 个以上从服务器，并且确认延迟小于M秒，主服务器接受写操作。

还可以把这看做是 CAP 原则（一致性，可用性，分区容错性）不严格的一致性实现，虽然不能百分百确保一致性，但至少保证了丢失的数据不会超过 M 秒内的数据量。

如果条件不满足，主服务器会拒绝写操作并返回一个错误。

1. min-slaves-to-write：最小从服务器数
2. min-slaves-max-lag：从服务器最大确认延迟