主库卡顿导致从库失联时，应先执行INFO replication检查connected_slaves、master_repl_offset和repl_backlog_active状态，再调大repl-backlog-size和client-output-buffer-limit，接着用SLOWLOG GET定位慢命令，最后校准Lettuce超时配置并排查大key。
主库卡顿导致从库失联，先看 INFO replication 确认状态
主库一卡，从库很快就会掉线，但现象未必是“连接拒绝”，更常见的是从库日志里反复出现 SYNC with master failed 或 Connection reset by peer。这时候别急着重启，先登录主库执行：
redis-cli INFO replication重点关注
connected_slaves、master_repl_offset 和 repl_backlog_active。如果 connected_slaves 为 0，但 repl_backlog_active 是 1，说明主库还在维持复制缓冲区，只是从库连不上或同步跟不上；如果 repl_backlog_active 是 0，那缓冲区早就被清空了——大概率是主库卡死或配置被重置。
config set repl-backlog-size 必须调大，但不能只靠它硬扛
主库卡顿期间新写入的命令全堆在复制缓冲区（repl-backlog），默认只有 1MB。一旦卡顿超时，缓冲区滚掉旧 offset，从库重连就只能触发全量同步——而全量同步又会加重主库压力，形成恶性循环。所以第一步是立刻扩容：
-
redis-cli config set repl-backlog-size 1073741824（即 1GB） - 同时配好客户端输出缓冲区：
redis-cli config set client-output-buffer-limit "slave 1073741824 536870912 60" - 这两项生效后，用
config get repl-backlog-size和config get client-output-buffer-limit验证是否真改成功
注意：这只能争取时间，不是根治方案。如果主库持续高负载，再大的 backlog 也会被冲垮。
查慢日志定位卡顿元凶，SLOWLOG GET 比监控更直接
主库卡顿往往不是 CPU 跑满，而是某个命令堵住主线程。比如一个 KEYS user:* 扫了 500 万 key，或者 ZUNIONSTORE 合并十几个大有序集合——这些都会让主库几秒无响应。直接查慢日志最准：
- 先设阈值：
CONFIG SET slowlog-log-slower-than 10000（记录 >10ms 的命令） - 再取最近 10 条：
SLOWLOG GET 10 - 重点看第三列耗时（单位微秒）和第四列命令详情，例如：
["LRANGE", "big_list", "0", "10000"]就很可疑
别依赖“平均延迟”指标——Redis 的 P99 延迟可能飙到秒级，而 avg 还不到 1ms。慢日志才是真实快照。
Lettuce 客户端超时配置必须和主库实际能力对齐
很多团队把 socketTimeout 设成 3 秒，结果主库一卡，Lettuce 就疯狂重连、重试、打满连接数，反而加剧主库负担。这不是客户端的问题，而是配置脱离了现实：
- 如果主库基线延迟是 0.5ms，但偶尔有 2s 的慢命令，
socketTimeout至少设为 3–5 秒，给主库喘息空间 - 同步命令超时（
commandTimeout）建议比 socketTimeout 略短，避免阻塞线程池 - 务必关掉自动重连的激进策略：
ClientOptions.builder().autoReconnect(false)，由业务层控制降级或熔断
最容易被忽略的一点：超时设置再合理，也救不了持续写入大 key 的场景。真正卡住主库的，常常是单个 SET 写入 10MB 的 JSON 字符串——这种操作不会出现在慢日志里（因为 SET 本身复杂度低），但分配内存过程会阻塞主线程。得靠 redis-cli --bigkeys 或 memory usage 主动挖。
