Redis replica-read-only 为什么不能保证只读一致性

replica-read-only yes 只能保证 Redis 副本拒绝客户端直接发来的写命令，不能保证客户端从副本读到刚写入主节点的数据。原因很直接：Redis 复制默认是异步的，主节点不会在每次写入后等待所有副本处理完成；副本即使“只读”，仍可能暂时落后于主节点。

官方地址：https://redis.io/docs/latest/operate/oss_and_stack/management/replication/

先把只读开关的职责迁移清楚

我在看读写分离配置时，第一件事不是检查“只读有没有开”，而是先问：这里要防止误写，还是要保证读到最新值？这两个目标看似接近，实际上属于不同层。

Redis 副本的只读模式默认开启。它会拒绝普通客户端发来的写命令，避免应用把副本当成主节点误写。但主节点发送的复制命令流不受这个限制，否则副本永远无法跟随主节点。也就是说，副本对客户端只读，对复制链路仍然必须可更新。

# 查看副本是否拒绝客户端写命令
redis-cli -h replica.example.internal CONFIG GET replica-read-only

# 查看节点角色与复制链路状态，不执行任何写操作
redis-cli -h replica.example.internal ROLE
redis-cli -h replica.example.internal INFO replication

如果配置返回 yes，只能说明误写保护存在。它没有回答副本当前落后多少，也没有承诺下一次读取能看到刚完成的主节点写入。

异步复制才是陈旧读的来源

Redis 主节点把改变数据集的命令持续发送给副本，副本再按自己的接收与处理进度更新数据。默认异步模式追求低延迟和吞吐：主节点处理写请求时，不会为每个命令等待所有副本完成。因此在网络抖动、主从处理速度不同、断链重连或全量同步期间，主从偏移量可能不同。

官方文档用 replication ID 和 offset 描述同一数据历史中的位置：ID 相同但 offset 不同，表示两边属于同一历史，却处在不同时间点。只读开关不会拉齐 offset，也不会阻塞客户端等待追平。

# 在主节点与目标副本分别查看 replication 区域
redis-cli -h primary.example.internal INFO replication
redis-cli -h replica.example.internal INFO replication

# ROLE 返回角色、链路状态和复制进度，适合程序化检查
redis-cli -h replica.example.internal ROLE

排查时重点看角色、主从连接状态、是否正在同步，以及两端复制进度。不要把一次读取成功当作链路健康证明；副本在某些同步配置下还能用旧数据集服务查询，这正是“可读”与“最新”不同的地方。

把旧的副本直读改成按一致性路由

如果旧方案是“写主节点，所有读随机发副本”，迁移时应把读请求分级，而不是只改一个 Redis 参数：

• 必须立即读到自己的写入：写完后在同一次业务链路回主节点读取，这是最清楚的策略。
• 允许短暂陈旧：列表、缓存预览、离线统计等读请求可以发副本，但要设置链路异常和同步期间的降级规则。
• 希望降低写入尚未复制的概率：可以在写入连接上调用 WAIT，等待指定数量副本确认此前写命令；随后仍要保证读取路由落到合适节点。

# 先在主节点写入业务值
redis-cli -h primary.example.internal SET order:42:state paid

# 等待至少 1 个副本确认当前连接此前的写入，最多等待 500 毫秒
redis-cli -h primary.example.internal WAIT 1 500

WAIT 返回的确认数量可以作为应用决策依据，但它不会把 Redis 变成强一致 CP 系统，也不能单独保证负载均衡器随后选择的任意副本就是已确认的那一个。严格读后写场景仍应读主节点，或由应用维护明确的副本选择与偏移量条件。

回归检查不要只测试写命令被拒绝

我更倾向把回归拆成四组，因为它们验证的不是同一件事：

• 写保护：普通应用账号向副本执行写命令时被拒绝。
• 复制健康：主从角色、连接状态和复制进度持续可观测，断链时触发降级。
• 读取语义：必须读新的请求回主节点，可容忍陈旧的请求才走副本。
• 故障切换：提升副本后，客户端拓扑刷新、写路由和读路由都能切到新角色。

另外，只读副本不等于可以暴露给不可信网络。官方文档明确提醒，DEBUG、CONFIG 等管理命令仍可能可用；网络隔离、认证和 ACL 仍需单独配置。

迁移清单

1. 保留 replica-read-only yes，把它定义为误写保护。
2. 给 INFO replication 或 ROLE 建立链路状态与复制进度监控。
3. 标记必须读后写一致的接口，让这些接口读取主节点。
4. 仅在能接受陈旧读的场景使用副本扩展读取。
5. 需要 WAIT 时处理超时和确认数量不足，不能无条件继续读任意副本。
6. 用 ACL、认证和网络边界保护副本，不把“只读”当安全策略。

常见问题

问：replica-read-only=yes 后副本为什么还在变化？
因为它只拒绝客户端写入，主节点的复制命令流仍会更新副本。

问：只读副本能保证读后写一致吗？
不能。默认异步复制存在传播和处理窗口，刚写入主节点的数据可能尚未到达目标副本。

问：WAIT 成功后能随便读任意副本吗？
不能直接这样推断。它确认的是指定数量副本处理了此前写入，读取路由还要保证选中合适节点。

问：为了避免延迟，可以把副本改成可写吗？
不建议。可写副本会引入与主节点不同的数据，重同步或重启时本地写入还可能被丢弃。