怎么用指标来判断Redis主从复制到底稳不稳定，实操思路分享

要判断Redis主从复制稳不稳定，不能光靠感觉，得看一些实实在在的指标，这就像看一个人身体好不好，不能光听他说，得量量体温、测测心跳，下面我就分享一些实操的思路，告诉你该看哪些地方,怎么看。

第一，先看最基础的两个状态指标：master_link_status 和 slave_read_only。

这两个指标是判断主从复制连接是否健康的“体温计”，你需要登录到从库Redis实例，使用 info replication 命令来查看。

• master_link_status：这个值必须是 up，如果它变成了 down，那就意味着从库和主库之间的网络连接断开了，这是最严重的不稳定情况，复制完全停止了,你必须立刻检查网络问题或者防火墙设置。
• slave_read_only：这个值通常应该是 1，表示从库处于只读模式，这是为了数据一致性，防止有人在从库上误写入数据，导致主从数据不一致，如果你发现这个值被设为了 0，那就要警惕了，可能有人误操作,这会埋下数据冲突的隐患。

根据Redis官方文档的说明，这两个是核心状态指标,必须首先确认它们正常。

第二，关注复制延迟，这是判断“稳定性”的关键指标。

即使主从连接是通的，数据也可能不同步，这就是复制延迟，延迟太大，从库的数据就是“过时”的，如果这时主库宕机,你切到从库就会丢失一部分最新数据。

怎么看延迟？还是用 info replication 命令,主要看这两个值：

• master_repl_offset：这是主库的复制偏移量，可以理解为数据写入的“总字节数”。
• slave_repl_offset：这是从库的复制偏移量，就是从库已经接收到的“总字节数”。

你需要在主库查看 master_repl_offset，在从库查看 slave_repl_offset，然后用主库的值减去从库的值，得到的就是延迟的字节数，这个差值如果长期保持在一个很小的、稳定的范围（比如几KB到几十KB），那说明复制很健康，如果这个差值在不断变大，或者突然飙升到几MB甚至更大，那就说明复制出问题了,从库跟不上主库的写入速度。

第三，深入一点，看看背后的“压力”指标。

为什么会产生延迟？通常是主从库的“压力”不匹配,你需要监控以下几个点：

• 主库的写入压力（QPS）： 使用 info stats 命令，关注 instantaneous_ops_per_sec 这个值，它表示每秒的操作数，如果这个值非常高，比如好几万,主库生产数据的速度可能超过了从库处理的能力。
• 从库的持久化压力（RDB）： 根据《Redis开发与运维》这本书里的分析，一个常见的瓶颈是，从库在加载RDB快照或者本身在做AOF重写时，会消耗大量CPU和磁盘IO，这时，从库处理主库复制流的能力就会下降，导致延迟增大，你可以通过 info persistence 命令查看从库是否正在 loading RDB文件或者 aof_rewrite_in_progress。
• 网络带宽： 主从之间的网络带宽是否足够？如果主库写入量很大，而网络带宽是100Mbps，很可能网络本身就成了瓶颈，你可以用系统工具（如 sar -n DEV 1）监控主从服务器网卡的出口和入口流量。

第四，观察是否有复制中断和重连的情况。

不稳定的另一个表现是复制连接“时好时坏”，频繁中断又重连,这会严重影响数据一致性。

在从库的 info replication 输出里，可以关注 master_link_down_since_seconds，它记录了连接已经断开了多久，更重要的是，你要去查看Redis的日志文件，如果日志里频繁出现诸如“Connection with master lost”、“I/O error trying to sync with MASTER”或者“Synchronization with master succeeded”这样的信息，就说明复制连接在反复震荡，这通常指向不稳定的网络环境或主从库的某个节点资源（如内存不足触发Swap）出现间歇性问题。

实操思路总结：

1. 日常检查： 写一个简单的脚本，定时（比如每分钟）去从库执行 info replication，采集 master_link_status、slave_read_only 和主从偏移量差值，设置报警规则，status 不是 up 就电话报警,延迟超过10MB就发告警邮件。
2. 深度排查： 当收到延迟报警时，按顺序检查：
   • 主库的瞬时QPS高不高？
   • 从库的CPU和磁盘IO使用率是不是满了？
   • 从库是否正在加载数据或重写AOF？
   • 用 ping 和 traceroute 检查主从之间的网络延迟和丢包率。
3. 历史分析： 使用监控系统（如Prometheus）持续采集上述所有指标，并绘制成图表，这样你不仅能看当前状态，还能回顾历史，看看延迟变大是否与某个时间点的主库业务高峰、从库定时任务或网络变更有关。

稳定不是一个“是”或“否”的问题，而是一个“程度”问题，你的目标就是通过监控这些指标，让复制的延迟尽可能小,并且避免出现连接中断的情况。