作者简介

马听，多年 DBA 实战经验，对 MySQL、 Redis、ClickHouse 等数据库有一定了解，专栏《一线数据库工程师带你深入理解 MySQL》作者。

从这篇文章开始，将出几期 Redis 运维实战相关的内容，大致包括：Redis 主从、Redis 集群、持久化、大 key、热 key、Redis 监控以及 Redis 规范等。

本节先从 Redis 主从复制开始聊。

首先来看 Redis 复制的配置：

1 配置 Redis 主从复制

1.1 配置复制

Redis 安装可以参考官方文档（https://redis.io/download），配置 Redis 主从复制的方法如下（本节内容的 Redis 版本为 6.0）：

直接登录 Redis 之后，在从节点执行如下命令：

replicaof {masterHost} {masterPort}

拓展：

Redis 5.0 之前配置复制是使用 slaveof 命令的，从 5.0 开始，可以使用 replicaof 配置复制，当然继续用 slaveof 也行的。

如果要停止复制，则在从节点执行如下命令即可：

replicaof no one

1.2 查看复制信息

使用下面命令可以查看复制信息：

info replication

这里解释一下上图参数所代表的含义：

那么在我们执行完 replicaof 命令后，Redis 是如何完成历史数据以及增量数据同步的？这里就需要聊到 Redis 的复制原理。

2 复制原理

第一次建立复制过程大致原理如下：

• 保存主节点信息：执行 replicaof 后从节点只保存主节点的地址信息便直接返回
• 主从建立连接：从节点内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接
• 发送 ping 命令：连接建立成功后，从节点发送 ping 请求进行首次通信
• 权限验证：如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置正确的 masterauth 才能通过验证，如果验证失败复制将停止。
• 同步数据集：主从连接正常后，主节点会执行 bgsave 保存 RDB 文件到本地，然后发送 RDB 文件到从节点，从节点会清空自身旧数据，然后把接收的 RDB 文件保存在本地并直接作为从节点的数据文件。对于从节点开始接收 RDB 到接收完成期间，主节点的增量命令会保存在复制客户端缓冲区内，当从节点加载完 RDB 文件后，主节点再把缓冲区内的数据发送到从节点，保证主从之间数据一致性。
• 命令持续复制：当从节点接收到所有数据后，则完成了复制的建立流程。接下来主节点会持续地把命令发送给从节点，保证主从数据一致。

在笔者几年的 Redis 运维工作中，多多少少会遇到一些与复制相关的问题。这里就选几个比较典型的来跟各位朋友分享，也方便你们在后续工作中绕过这些坑。

3 复制常见问题

3.1 主从延迟

由于 Redis 复制为异步复制模式，因此延迟无法避免。

判断主从节点延迟的方式是：主节点 info replication 的 master_repl_offset 和 slave0 字段的 offset 指标的差值，就是主从节点延迟的字节量。如下图：

可以看出该实例 master_repl_offset 和 slave0 字段的 offset 指标一样，因此主从没延迟。

应对延迟的方式：

可以对主从延迟进行监控，如果发现延迟，业务对数据一致性要求比较高的场景，则查询改成只走 master。如果经常性出现延迟，则建议采用集群方案。

3.2 读到过期数据

Redis 删除过期数据有两种策略：

惰性删除：主节点每次处理读取命令时，都会检查键是否过期，如果过期则执行 del 命令删除键对象，之后 del 命令也会同步到从节点，并且从节点自身不会主动删除过期数据。

定时删除：Redis 主节点内部的定时任务会循环采样一定数量的键，当发现采样的键过期时，执行 del 命令，之后再同步给从节点，如果此时有大量的键超时时，主节点采样删除的速度跟不上过期速度，且主节点没有读取过期键的操作，那么从节点将无法收到 del 命令。此时在从节点上可以读取到已经超时的数据，这种情况通常不是我们希望的。

因此在 Redis 3.2 版本解决了这个问题：从节点读取数据之前会检查键的过期时间来决定是否返回数据。

3.3 全量复制

Redis 2.8 以前的版本，只支持全量复制，如果出现网段闪断等情况，都需要重新进行全量复制，这会对主节点和网络造成很大的开销。

而在 2.8 及以上的版本，使用了 psync 命令完成主从数据同步，当同步短时间中断，主节点会把断连期间收到的写操作命令，写入 replication buffer，同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。

从节点再次连上主节点时，会发送 psync 命令给主实例，并把自己当前时间点的 slave_repl_offset 发给主库，主节点会判断自己 master_repl_offset 和 slave_repl_offset 之间的差距。主节点再把 master_repl_offset 和 slave_repl_offset 之间的命令操作同步给从节点就行。

那么，到底中断到什么程度才不能继续进行增量同步了呢？这里又回到上面 repl_backlog_buffer 这个缓冲区的概念。

repl_backlog_buffer 是一个环形缓冲区，所以在缓冲区写满后，主节点会继续写入，此时，就会覆盖掉之前写入的操作。如果中断时间过久，就可能导致从库还未读取主库的操作，主库 repl_backlog_buffer 一部分就已经被覆盖了，从而导致主从数据不一致。

因此，为了避免主从节点数据不一致的情况，建议把 repl_backlog_buffer 调整的大一点。根据以往的经验，如果主从网络要调整的情况下，可以根据网段大致中断时间，然后判断该组 Redis 前几天这个时间段的内存增量，然后把 repl_backlog_buffer 调整为这个内存增量的两倍。

注：笔者在几年前就遇到过类似问题，当时使用的 Redis 版本是 2.4，存在跨机房复制的场景，某次网络波动导致重新全量同步，从而导致专线网络告警。最终升级 Redis 版本到 3.x ，网络短时间波动不再需要全量复制了。

3.4 复制风暴

复制风暴的一种情况是：一个主节点有多个从节点时，当主节点重启后，从节点会发起全量复制流程，根据上面讲的复制原理，主节点会创建 RDB 快照，而其他节点将共享这一份快照（Redis 在这里做了优化，防止创建多个快照）。此时，可能会出现这个主节点同时向多个从节点发送 RDB 快照，可能会把主节点所在机器的网卡流量跑满，从而导致主从延迟或者中断等问题。解决办法是减少主节点挂载从节点的数量，或者采用树状复制结构。

复制风暴的另一种情况是：一台机器跑了多个 Redis 节点，如果机器重启，会导致这台机器上多个主节点的 RDB 往其他机器传输，同样可能导致机器的网卡流量跑满，或者主从延迟甚至中断等问题。解决办法是主节点尽量分在多台机器上，或者提供故障转移机制。

4 复制相关建议

最终，在 Reids 复制相关功能使用中，笔者个人建议有下面这些（当然如果各位朋友有其他的一些经验建议，也欢迎在下方留言区留言补充）：

• 建议在低峰时进行新的主从配置。
• 建议使用 3.2 及以上的版本。
• 建议一个主节点别挂载太多的从节点。
• 建议一台物理机上运行尽可能少的主节点。