必须验证读请求是否真正路由到从节点并监控复制延迟，否则读写分离无效；需通过客户端拓扑发现、CLIENT LIST观察连接、INFO replication比对offset差值及压测分离路径来确认。
读写分离性能不能只看吞吐量，得先确认读请求真走到了从节点、且延迟在可接受范围内。 否则所谓“提升”只是幻觉——你可能还在主节点上扛读流量，或者从节点数据滞后几秒，业务已经出问题了。
验证读请求是否真的路由到从节点
很多配置看似启用了读写分离，但客户端根本没识别主从拓扑，所有读仍打到主节点。关键要看客户端是否完成「拓扑发现」：
- 用
Lettuce时，必须配置read-from: REPLICA_PREFERRED或REPLICA，且启动后连接任意节点（如从节点127.0.0.1:6380），客户端会自动执行INFO replication获取主从关系并建立路由表 - 用
Redisson时，setReadMode(ReadMode.SLAVE)必须生效，且addSlaveAddress()中的地址要能连通；若从节点未正确声明replica-announce-ip和端口，Redisson 会 fallback 到主节点读 - 手动验证：用
redis-cli -p 6380连从节点，执行CLIENT LIST，观察是否有来自你应用的连接；再在应用中执行一次get，立刻查该从节点的INFO stats中instantaneous_ops_per_sec是否跳变
监控从节点数据延迟（不是网络延迟）
异步复制必然存在 lag，但 lag 多大才算安全？不能只看 master_repl_offset - slave_repl_offset 的差值，得结合写入节奏和业务容忍度：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在从节点执行
INFO replication，关注三项：master_repl_offset、slave_repl_offset、master_sync_in_progress（是否正在全量同步） - 差值
repl_lag_bytes = master_repl_offset - slave_repl_offset是字节数，不是毫秒；若主节点写入频繁（如每秒 10KB 命令流），差值 50KB ≈ 5 秒延迟 - 生产环境建议设置告警阈值：差值持续 > 1MB 或 lag 时间估算 > 2 秒，需检查网络、从节点 CPU/IO、
repl-backlog-size是否过小 - 注意：
slave_repl_offset在从节点重启后重置为 0，此时差值极大，但不等于真实 lag —— 要等同步恢复后再看稳定差值
压测时必须区分「读路径」和「写路径」
用 redis-benchmark 直接压测单个地址，结果毫无意义。真实读写分离下，读压测目标是「从节点集群」，写压测目标是「主节点」：
- 读压测命令示例：
redis-benchmark -h 127.0.0.1 -p 6380 -c 100 -n 10000 -t get,set（只测get，排除set干扰） - 写压测命令示例：
redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t set（限制并发数，避免压垮主节点） - 对比指标：主节点
used_cpu_sys和instantaneous_ops_per_sec是否显著下降；从节点平均响应时间是否稳定在 - 陷阱：如果压测工具本身连接的是主节点地址，即使配置了读写分离，也可能因连接复用绕过路由逻辑 —— 务必用客户端 SDK（如 Spring Data Redis）封装的
redisTemplate.opsForValue().get()发起请求
真正卡点不在配置对不对，而在「从节点是否被当成只读缓存用」—— 它的数据新鲜度、连接池是否耗尽、故障时是否静默 fallback 到主节点。这些细节不暴露在日志里，只能靠 INFO replication、CLIENT LIST 和业务层埋点交叉验证。
