redis cluster不支持跨槽事务，大事务导致的复制中断实为主节点复制缓冲区溢出；需同步调大repl-backlog-size和client-output-buffer-limit slave参数，并避免全量扫描类命令。
大事务在Redis Cluster中根本无法执行
Redis Cluster不支持跨槽事务，MULTI/EXEC 只能在单个哈希槽内原子执行。一旦命令涉及多个键（比如 KEYS、SCAN、或多个不同槽的 SET），集群会直接返回 CROSSSLOT Keys in request don't hash to the same slot 错误——根本不会走到复制阶段，更谈不上“中断”。所谓“大事务导致复制中断”，实际是误判：真正出问题的是单节点上的主从复制链路，而非Cluster分片逻辑本身。
真正被压垮的是主节点的复制缓冲区
当主节点上出现长耗时操作（如 LRANGE biglist 0 -1、HGETALL hugehash、未加 SCAN 游标的全量遍历），它会阻塞主线程数毫秒至数秒。这期间：新写命令仍持续进入复制积压缓冲区（repl-backlog-size），而主节点又无法及时把增量命令推送给从节点（因为线程卡着），导致从节点的 slave_repl_offset 滞后；同时，主节点的客户端输出缓冲区（client-output-buffer-limit slave）也在堆积待发送数据。两者任一溢出，都会触发强制断连。
- 用
INFO replication查看master_repl_offset − slave_repl_offset差值是否持续增大 - 检查
redis-cli --stat输出中sync_partial_ok是否为 0，若长期为 0，说明部分重同步已失效 - 确认主节点日志是否频繁出现
Client id=xxx flags=SLAVE: output buffer length exceeds limit
必须同步调整两个缓冲区参数
repl-backlog-size 和 client-output-buffer-limit slave 是一对绑定参数，只调一个等于白做。高压下主节点要三线并行：生成RDB（如果触发）、写增量到积压缓冲区、向从节点发数据——三者共用同一内存压力面。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 立即生效：运行
CONFIG SET client-output-buffer-limit "slave 1024mb 512mb 120"，避免缓冲满即断连 - 同步执行：
CONFIG SET repl-backlog-size 1024mb，确保从节点断连重连后能追上（注意：该值不能超过client-output-buffer-limit中的硬限制） - 持久化配置：把这两项写进
redis.conf，否则重启后恢复默认值（256mb / 64mb / 60秒） - 别碰
repl-backlog-ttl：设太长（如 >7200）会让积压缓冲区常驻高内存，且对防中断无效；默认3600已足够，重点是把 size 扩容
业务层唯一可控动作：拆、限、读主
Redis Cluster 本身不提供事务一致性保障，复制中断后的数据差异无法自动修复。靠 WAIT 在集群模式下也受限（仅作用于当前槽），且会放大延迟。
- 禁止在主节点执行任何全量扫描类命令：用
SCAN+ 游标分批，控制每次响应大小 - 对大集合操作（如
LRANGE、HGETALL）加服务端超时或客户端熔断，避免卡死主线程 - 关键读场景（如支付后查余额、下单后查库存）绕过从节点，直连主节点——
connected_slaves=1不代表数据一致，偏移量差才是真实指标 - 升级到
Redis 8.2.3：该版本修复了CVE-2025-62507RCE 漏洞，并稳定了Cuckoo Filter在高压下的行为，减少因数据结构异常引发的隐性卡顿
最容易被忽略的一点：复制中断往往不是突然发生的，而是从偏移量缓慢漂移、到突增、再到全量同步这样一个渐进过程。监控 master_repl_offset − slave_repl_offset 的变化速率，比单纯盯 connected_slaves 有效得多。
