全量同步时master卡住的主因是fork()系统调用阻塞主线程，而非rdb写磁盘；需通过latest_fork_usec飙升、cpu使用率同步上升及rdb_changes_since_last_save停滞综合判断，大key和透明大页（thp）会显著加剧fork耗时。
全量同步时Master卡住，先看bgsave是否真在跑
主节点在全量同步阶段会触发bgsave生成RDB，但真正拖慢主线程的不是RDB写磁盘，而是fork()系统调用本身。只要INFO stats里latest_fork_usec突然飙升到几百毫秒以上，就说明fork正在阻塞主线程——此时客户端延迟尖峰、repl-backlog积压、从库offset停滞都会跟着出现。
别只盯着bgsave_in_progress:1这个字段，它只表示子进程已启动；要确认阻塞源，得同时查：
• used_cpu_sys和used_cpu_user是否同步飙升
• redis-cli --stat输出中rdb_changes_since_last_save是否长期不更新
• 日志里有没有Fork operation complete之前的长时间空白
大Key和THP是fork耗时翻倍的两大元凶
20GB内存的Redis实例，fork可能耗时500ms+，但如果存在单个hash含8万field或zset超千万成员，fork时间很容易突破2秒。更隐蔽的是Linux透明大页（THP）：若/sys/kernel/mm/transparent_hugepage/enabled显示[always]，fork单位从4KB变成2MB，复制页表开销直接翻倍。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
• 用redis-cli --bigkeys扫出元素数>5000或MEMORY USAGE>1MB的key，优先拆分
• 执行echo never > /sys/kernel/mm/transparent_hugepage/enabled并重启Redis
• 单实例内存尽量控制在16GB以内；超大容量场景宁可分片，不硬扛fork
client-output-buffer-limit配置不当会触发恶性循环
全量同步时主库一边bgsave，一边要把整个RDB发给从库。如果client-output-buffer-limit slave设得太紧（比如默认的256mb 64mb 60），主库还没发完RDB，输出缓冲区就超软限制了，立刻断连——从库重连后又触发新一轮bgsave，形成“断连→全量→再断连”死循环。
安全配置要点：
• 硬限制至少设为1024mb（环形缓冲不怕设大）
• 软限制建议512mb + 时间放宽到300秒，避免RDB传输中途被杀
• 动态生效命令：CONFIG SET client-output-buffer-limit "slave 1024mb 512mb 300"
• 别忘了同步改redis.conf，否则重启失效
绕过fork阻塞的唯一可靠路径是不让Master生成RDB
想彻底避开bgsave阻塞，就得放弃主节点承担RDB生成任务。生产环境最稳的做法：
• 主节点CONFIG SET save ""清空所有自动保存规则
• 开启AOF：appendonly yes
• 启用混合持久化：aof-use-rdb-preamble yes
• 把RDB生成压力转移到从节点：只在从节点配save 300 1等低频规则
这样主节点只做命令复制和AOF写入，fork()完全消失。但要注意：AOF重写期间仍会触发bgrewriteaof，所以也得关THP、控内存、避高峰。
