Redis 7.0+中client-output-buffer-limit slave已失效，改由repl-backlog-size统一管理复制积压缓冲区；需设大repl-backlog-size（按写入速率×断连容忍时间×1.5）、调高repl-backlog-ttl，并确认repl_backlog_active=1才生效。
Redis 7.0 中从节点输出缓冲区已不归 client-output-buffer-limit 管
Redis 7.0（及更高版本）主节点不再为从节点维护 client-output-buffer-limit slave 类型的输出缓冲区。这个机制在 Redis 5.0 后逐步废弃，7.0 完全由 repl-backlog-size 统一接管——它是一个全局、环形、主节点侧的复制积压缓冲区，所有从节点共享同一份 offset 历史数据。
所以你搜到的类似 client-output-buffer-limit slave 256mb 64mb 60 配置，在 7.0+ 生产环境中不仅无效，还会造成误解：它不会被加载，INFO replication 里也看不到对应指标变化。
常见错误现象：
– 修改了 redis.conf 中的 client-output-buffer-limit slave 并重启，但 CLIENT LIST 里仍无 omem 显著增长，或断连后依然全量同步
– CONFIG GET client-output-buffer-limit 返回结果包含 slave 行，但实际不生效（只是配置残留）
真正该调的是 repl-backlog-size 和 repl-backlog-ttl
主节点复制缓冲区大小和存活时间，才是决定从节点重连能否增量同步的关键：
-
repl-backlog-size必须手动设大：默认 1MB 在任何真实写入场景下都不够；按公式算 ——平均写入速率（B/s）× 最长容忍断连时间（s）× 1.5 -
repl-backlog-ttl要略大于你的最大断连窗口：比如运维升级允许断连 180 秒，那就设成240；设太小（如60），哪怕缓冲区够大，也会因“过期销毁”导致 offset 找不到 - 必须确认
repl_backlog_active == 1：用INFO replication查；为 0 说明缓冲区根本没初始化——此时CONFIG SET repl-backlog-size不会分配内存
临时激活方法：起一个测试从节点连上来，等 repl_backlog_active 变 1 后再断开，新 size 才真正载入。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么不能只靠 client-output-buffer-limit pubsub/normal 来保从节点
这两类限制完全不作用于复制链路：
-
client-output-buffer-limit pubsub只管 SUBSCRIBE 客户端，不影响从节点连接（即使它底层也用 RESP 协议） -
client-output-buffer-limit normal只管普通命令响应，比如你用 redis-cli 执行LRANGE，和从节点的 SYNC/PSYNC 流程无关 - 从节点连接在
CLIENT LIST中flags字段显示为S（slave）或R（replica），不属于normal或pubsub分类
误配这两项，既不能防止全量同步，还可能因策略冲突干扰正常客户端（比如把 normal 的 hard-limit 设太小，导致业务 pipeline 被频繁踢掉）。
检查与验证的三步实操
上线前必须跑通这三步，缺一不可：
- 执行
INFO replication，确认repl_backlog_active:1、repl_backlog_size等于你设的值（单位字节）、repl_backlog_first_byte_offset不为 0 - 模拟从节点断连：停一个从节点 2 分钟（确保小于你设的
repl-backlog-ttl），再启动；观察日志是否出现Partial resynchronization not possible—— 出现即失败 - 用
redis-cli -p 6379 CLIENT LIST过滤出从节点连接（flags=S），检查其omem字段是否稳定（理想是几百 KB 内波动），而非持续上涨
最容易被忽略的是：repl-backlog 是环形缓冲区，不存完整命令，只存字节流；offset 对不上就只能全量——所以 ttl 和 size 必须协同，且必须等它真正激活后才算数。
