一眼识别主从延迟失控：执行info replication，检查master_repl_offset、slave_repl_offset和lag；若差值持续＞50000或lag＞3不回落，说明滞后；差值达百万级或停滞，多为同步卡死或断网。
怎么一眼看出主从延迟已经失控
别等业务报错才查，直接连上主节点执行 info replication，盯住三个字段：master_repl_offset、slave_repl_offset 和 lag。如果 master_repl_offset - slave_repl_offset 持续大于 50000（约对应几秒延迟），或 lag > 3 且不回落，说明复制链路已明显滞后；若差值飙到百万级甚至停滞不动，基本就是同步线程卡死或网络断开。
repl-disable-tcp-nodelay 设成 no 真的能救命吗
能，但只在特定条件下有效——高频小命令写入（比如每秒几百个 SET）+ 局域网环境 + 网络无丢包。默认值 yes 启用 Nagle 算法，会攒包等满或超时（通常 200ms）才发，直接把复制流“卡顿”成秒级。实操上：
- 先确认当前值：
CONFIG GET repl-disable-tcp-nodelay，返回["repl-disable-tcp-nodelay","yes"]就该改 - 临时生效：
CONFIG SET repl-disable-tcp-nodelay no - 持久化：在
redis.conf中写明repl-disable-tcp-nodelay no，再执行CONFIG REWRITE验证是否落盘 - 注意：它只影响主→从的复制流，不影响客户端连接，也不解决 BigKey 或磁盘慢的问题
改完反而更抖？立刻检查 netstat -s | grep -i "segments retransm" 的重传数是否飙升——这说明禁用 Nagle 后小包激增，暴露了底层网络丢包或中间设备（如云 SLB）处理低效的问题。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么调大 repl-backlog-size 还是触发全量同步
因为 repl-backlog-size 是环形缓冲区，大小固定，旧数据会被覆盖。当从节点断连时间超过缓冲区能容纳的写入量，或主节点写入突增导致缓冲区瞬间填满，就会丢失部分 offset 区间，触发 SYNC 全量同步。判断是否溢出的关键指标是 repl_backlog_histlen 接近 repl_backlog_size，且日志出现 Master does not have enough backlog。
估算合理值的方法很直接：主节点平均每秒写入字节数 × 期望容忍的断连恢复时间（秒）。例如每秒写 500KB，要扛住 60 秒断连，至少设为 30000000（30MB）。动态调整用 CONFIG SET repl-backlog-size 30000000，但注意该操作不会清空现有 backlog，新大小只在下次创建时（如从节点重连）生效。
读到脏数据时，代码里最该加哪一行判断
不是加缓存、不是调参数，而是按业务敏感度分流：关键路径强制读主。比如库存扣减、余额变更、订单状态更新这类操作，必须绕过读写分离逻辑，直连主节点。Java 示例中核心就这一行：if(isCriticalData){... // 走主库连接}。这个判断不能模糊，得落在具体业务语义上——不是“所有写之后都要读主”，而是“哪些读的结果直接影响下一步写或用户感知”。忽略这点，再好的网络和配置也挡不住脏数据漏进前端。
