如何验证Redis主从架构的读写分离配置？-Redis-PHP中文网

最直接的验证方式是用 redis-cli monitor 查看写请求是否只打到主节点：主节点应仅出现 set、del、incr 等写命令，从节点 monitor 输出应为空或仅有 get 类读命令；同时通过 info replication 检查 master_repl_offset 与 slave_repl_offset 差值（超1000需调大 repl-backlog-size），并用 role 命令确认主从角色及连接状态。

如何验证redis主从架构的读写分离配置？

用 `redis-cli monitor` 看写请求是否只打到主节点

这是最直接的验证方式：主节点只应接收 SET、DEL、INCR 等写命令，从节点不应出现这些日志。

操作步骤：

在主节点执行 redis-cli -a yourpass monitor | grep -E "(SET|DEL|INCR|HSET)"
在应用端发起一次写操作（如保存用户 session）
确认该命令只出现在主节点输出中，且从节点的 monitor 输出为空或仅有 GET 类命令

注意：monitor 是高开销命令，生产环境仅临时启用，验证完立即停掉。

查 `info replication` 确认主从角色和复制偏移量差值

角色识别错误会导致读写分流失效；复制延迟过大则读不到最新数据。

分别在主、从节点执行：

主节点：redis-cli -a yourpass info replication | grep master_repl_offset → 记下数值（如 master_repl_offset:123456）
每个从节点：redis-cli -a yourpass info replication | grep slave_repl_offset → 对比差值
差值超过 1000 表示滞后严重，需调大 repl-backlog-size（建议设为 104857600 即 100MB）

若从节点显示 master_link_status:down，检查网络连通性、防火墙、masterauth 是否匹配。

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

用 `ROLE` 命令验证客户端是否能自动识别拓扑

Lettuce/PhpRedis 等智能客户端依赖 ROLE 或 INFO REPLICATION 构建主从关系图。如果返回异常，客户端会 fallback 到单点模式。

在任意节点执行：

redis-cli -a yourpass ROLE
主节点应返回 ["master",n,["192.168.1.11","6379"],["192.168.1.12","6379"]]（含从节点列表）
从节点应返回 ["slave","192.168.1.10","6379","up",123456]（含主节点地址和状态）

如果从节点返回 ["slave","","","down",0]，说明连接主节点失败，slaveof 配置或网络不通。

Spring Boot 中强制走主节点读取验证强一致性场景

read-from: REPLICA_PREFERRED 默认行为是“读从、写主”，但下单后立即查订单这类场景必须绕过从节点。

临时切换：在业务代码中加 @Transactional + RedisTemplate.setEnableTransactionSupport(true)，或手动指定连接工厂指向主节点
更稳妥的做法是封装一个 masterReadTemplate Bean，其连接池只配置主节点地址
测试时对比：同一 key 在写入后立刻用 masterReadTemplate 和默认 redisTemplate 分别读，确认后者可能有延迟

真正容易被忽略的是复制延迟边界——哪怕配置全对，从节点也可能落后几百毫秒。业务层必须明确哪些读可以容忍旧数据，哪些不能。