redis主从复制卡顿延迟飙升的典型表现是master_repl_offset与slave_repl_offset差值持续扩大、sync_full_ok频发，根本原因是fork子进程阻塞主线程，尤其内存大时fork耗时长导致repl-backlog溢出。
主从复制卡顿、延迟飙升的典型表现
当 Redis 主实例写入 QPS 超过 2 万，或单个 key 的 value 超过 10 MB（比如大 JSON 或序列化对象），INFO replication 中的 master_repl_offset 和从库 slave_repl_offset 差值会持续扩大，redis-cli --stat 可见 sync_partial_ok 极少而 sync_full_ok 频发——这说明从库频繁断连重同步，全量复制反复触发。
根本原因不是带宽不足，而是主库 fork 子进程生成 RDB 时阻塞主线程，而 fork 耗时与主进程内存占用呈近似线性关系。实测 20 GB 内存实例 fork 耗时常超 800 ms，期间所有写命令排队等待，复制缓冲区（repl-backlog）极易溢出，强制从库降级为全量同步。
分片不是加节点，而是按写负载切主库
盲目增加从库数量只会加重主库复制压力：每个从库都需独立维护复制缓冲区、独立接收相同数据流。真正有效的分片是把写流量分散到多个主实例，让每个主库只承担部分数据集和写压力。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redis-shake或redis-port按业务维度迁移数据（如用户 ID 取模、订单时间分段），避免哈希倾斜 - 主库配置必须显式设置
repl-backlog-size≥ 2 × 峰值写入量 × 预估网络抖动时长（例如：50 MB/s × 60 s = 3 GB → 设为3gb） - 禁用
repl-diskless-sync yes：磁盘同步虽慢但稳定；无盘同步依赖子进程直接 socket 发送，大 RDB 下易因 TCP 缓冲区满而中断，反而触发更多全量同步
从库不等于只读备份，要参与写扩散链路
纯一主多从架构下，所有从库都从同一主库拉取数据，形成“扇出瓶颈”。可构建级联复制链：master → replica-A → replica-B，但必须满足两个前提：
- 中间从库（replica-A）必须开启
replica-serve-stale-data no和replica-read-only yes，防止脏读或误写 - 关键参数
repl-timeout要逐级放大（主→A 设为 60，A→B 设为 90），否则下游超时断连会向上游传播，引发雪崩式重同步 - 禁止跨级写扩散（如 master → B），Redis 不支持多源复制，
SLAVEOF切换后原复制关系立即清除，无平滑过渡
监控不能只看 connected_slaves
connected_slaves 为 3 只代表连接数正常，无法反映实际复制质量。真正要盯住的是：
-
master_last_io_seconds_ago：大于 10 秒即告警，说明主从间心跳或数据流异常 -
slave0:ip=...,port=...,state=online,offset=...,lag=12中的lag值，持续 > 50 表示从库追不上 - 用
redis-cli -h $host -p $port --rdb /dev/null定期探测 RDB 生成是否卡死（超时即失败）
分片后各主库的复制状态必须独立监控，一个分片延迟不能靠其他分片“均摊”掩盖——延迟是局部问题，不是全局指标。
