必须按“峰值写入速率×最大断连时间”计算并上浮30%～50%，1MB默认值在真实业务中不足；峰值速率应取redis-cli info replication中net_input_bytes每秒增量的P95值，最大断连时间须依据历史最长失联记录（如137秒）或维护窗口确定。
必须按“峰值写入速率 × 最大断连时间”来算，再上浮 30%～50%，1MB 默认值在任何真实业务中都不够用。
怎么拿到靠谱的峰值写入速率
别看 instantaneous_ops_per_second 就直接乘个平均命令大小——它反映的是命令数，不是字节数。真正要的是主节点每秒往复制流里塞了多少字节。
- 最准的方法：用
redis-cli info replication查net_input_bytes每秒增量，取过去 1 小时的 P95 值（不是平均值） - 次选方案：用 Prometheus +
redis_exporter抓redis_commands_total{cmd=~"set|lpush|hset|zadd"}的速率，再乘以你业务里典型命令的平均响应体大小（含协议开销，一般 SET 是 200–300B） - 别依赖
master_repl_offset - slave_repl_offset差值——那是快照，不是压力窗口下的真实吞吐
最大断连时间不能只看“平均抖动”
这个值决定缓冲区能兜住多久的数据，必须按你环境中「最慢/最不稳定」的那个从节点来定，而不是集群平均。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 查运维日志里
Connection with master lost到MASTER REPLICA sync started的间隔，取历史最长的一次（比如 137 秒） - 用
redis-cli --latency-history -i 1跑 10 分钟，看 95% 分位的延迟毛刺持续时间 - 如果从节点要滚动升级或网络策略变更，把维护窗口时间也加进去（比如计划内停机 5 分钟，就至少按 300 秒算）
CONFIG SET 后为什么 repl_backlog_histlen 不涨
不是配置没生效，是缓冲区根本没被激活——repl_backlog_active 为 0 时，Redis 压根不分配内存。
- 执行
redis-cli info replication | grep repl_backlog_active，确认输出是repl_backlog_active:1 - 这个缓冲区只在「至少有一个从节点完成过一次成功同步」后才会初始化；长期没从节点，
CONFIG SET只改了配置值，不触发内存分配 - 临时解法：起一个测试从节点连上来，等
repl_backlog_active变 1 后立刻断开；此时新repl-backlog-size才真正载入 - 注意：
CONFIG SET不持久化，必须同步改redis.conf并执行CONFIG REWRITE，否则重启就回退
调完 size 还得配 repl-backlog-ttl
缓冲区不是永久存在的，repl-backlog-ttl 控制它“死后”还能活多久——设太短，照样全量同步。
- 默认是 3600 秒（1 小时），但如果从节点断连 120 秒才恢复，而你设成 60 秒，那它一 reconnect，缓冲区早被释放了
- 建议值 = 最长预期断连时间 × 1.5，比如容忍 120 秒断连，
repl-backlog-ttl至少设 180 秒 - 这个参数和
repl-backlog-size无关，只影响缓冲区生命周期；但两者不匹配，size 再大也没用
真正容易被忽略的是：这个缓冲区是纯字节累积的环形区，不记录时间、不区分命令、不按 offset 对齐——只要写入字节数超了，老数据就覆盖。所以计算时必须用峰值速率，而不是日常均值；验证时要看 repl_backlog_histlen 是否稳定在 repl_backlog_size 的 30%–70% 区间，太高说明还是小，太低说明冗余。
