repl-backlog-ttl 是 redis 主节点在无从节点连接时自动释放复制积压缓冲区的时间阈值，默认3600秒；超时后清空 backlog，导致重连从节点无法部分同步而触发开销巨大的全量同步。
repl-backlog-ttl 是什么，为什么它影响主从断连恢复？
repl-backlog-ttl 控制 Redis 主节点上复制积压缓冲区（replication backlog）在**无从节点连接时的自动释放时间**。默认值是 3600（1小时）。一旦所有从节点断开，倒计时开始；归零后，主节点清空 backlog 并释放内存。
问题就出在这里：如果从节点断连超过这个时限，再重连时无法走部分同步（PSYNC），只能触发全量同步（FULLRESYNC）——这意味着 bgsave + RDB 传输 + 从节点清空旧数据，CPU、内存、网络压力陡增，延迟飙升。
所以调大 repl-backlog-ttl 不是为了“让 backlog 永远不删”，而是为意外断连（如网络抖动、从节点重启、运维操作）争取足够宽裕的窗口，保住 PSYNC 的可能性。
怎么安全地调大 repl-backlog-ttl？
直接改配置文件或 CONFIG SET 都可以，但必须配合其他参数一起看，否则可能白调甚至引发新问题：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
repl-backlog-size必须足够大——如果 backlog 本身太小，哪怕保留 24 小时也没用，旧命令早被新命令覆盖了 -
repl-backlog-ttl建议设为略大于你最长预期断连时间，比如 7200（2 小时）或 14400（4 小时），不建议设为 0（永不释放），会导致内存持续占用且无法回收 - 修改后用
CONFIG GET repl-backlog-ttl和INFO replication确认生效，注意backlog_size和backlog_first_byte_offset是否稳定增长 - 线上环境优先用
CONFIG SET repl-backlog-ttl 7200热生效，验证无误后再写入redis.conf
常见误判：明明调大了 ttl，还是频繁全量同步？
这通常不是 repl-backlog-ttl 的锅，而是以下原因更常见：
- 从节点断连期间，主节点写入量极大，
repl-backlog-size不够，导致 offset 被覆盖（查INFO replication中的backlog_histlen是否长期接近repl-backlog-size） - 从节点重连时发送的
run_id已失效（比如主节点重启过），此时即使 backlog 还在，也无法 PSYNC - 网络丢包严重，从节点反复重试但始终无法完成握手，超时后主动放弃 PSYNC，降级为 FULLRESYNC
- 客户端使用了不支持 PSYNC2 的老版本 Redis 客户端（如某些 Lua 脚本直连方式），强制走旧协议
真实场景下的取舍点
延长 repl-backlog-ttl 本质是在「内存占用」和「恢复效率」之间做权衡。一个 100MB 的 backlog 保留 4 小时，比保留 1 小时多占约 300MB 内存（按写入速率估算），但这能避免一次可能持续数分钟的全量同步。
真正容易被忽略的是：这个参数只在「完全无从节点连接」时起作用。只要还有一个从节点在线，backlog 就不会被清理，repl-backlog-ttl 压根不计时。所以它救不了「主节点重启」或「所有从节点同时掉线」这种极端情况——那得靠 repl-diskless-sync 或 repl-diskless-sync-delay 配合优化。
