Redis主从同步中大Key会导致复制中断或延迟飙升，因其单次序列化传输阻塞复制流、触发超时断连及缓冲区溢出；需用渐进式扫描分批拆分并双写保障一致性。
主从同步时大Key导致复制中断或延迟飙升
Redis主从复制过程中，如果某个key是大Key（比如几MB甚至上百MB的hash、zset或list），主节点会把整个key序列化后通过REPLCONF协议一次性发给从节点。这不仅占用大量带宽，还会阻塞其他命令的复制，造成从节点master_repl_offset严重落后，甚至触发timeout断连。
典型现象包括：INFO replication中slave_repl_offset长期停滞、net_output_bytes突增、从节点日志频繁出现Timeout waiting for bulk read。
- Redis 6.0+ 虽支持
repl-diskless-sync yes减少磁盘IO，但不解决大Key单次传输问题 -
client-output-buffer-limit slave默认值（256MB/64MB/60s）很容易被一个大Key打穿，直接断连 - 主节点
redis-cli --bigkeys能发现大Key，但不会告诉你它正在拖垮复制
用HSCAN/SSCAN等渐进式命令拆分大hash/set
不能直接HDEL或DEL大Key——这会造成主节点瞬间高CPU和阻塞，且删除操作本身又会作为一条大命令同步到从节点，形成二次冲击。
正确做法是：在业务低峰期，用游标方式分批读取+写入新结构，再逐步清理旧Key。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 对大
hash：用HSCAN myhash 0 COUNT 100每次拉100个field，写入myhash:shard001等新Key，再HDEL原field - 对大
set：用SSCAN myset 0 COUNT 500，写入myset:part1~myset:partN，最后SREM原成员 - 务必在主节点执行，确保所有操作都进入AOF和复制流；从节点只读，不参与拆分逻辑
- 拆分脚本里加
SLEEP 0.01（如用redis-cli --eval配合Lua）避免压垮主节点
避免LRU/LFU驱逐加剧大Key问题
当内存紧张触发淘汰时，Redis默认按volatile-lru或allkeys-lfu策略选Key。若大Key恰好被选中，DEL它会产生巨量释放事件，同步到从节点又是一次带宽洪峰。
- 配置
maxmemory-policy noeviction可规避，但需确保业务有兜底内存控制 - 更稳妥的是：用
MEMORY USAGE bigkey定期扫描，结合OBJECT FREQ和OBJECT IDLETIME判断是否真冷数据，再人工介入拆分 - 禁止用
CONFIG SET maxmemory-policy在线切换策略——该命令会阻塞主线程，且切换瞬间可能批量淘汰
监控必须覆盖bigkey + replication lag双维度
只看lag指标（如slave_repl_offset - master_repl_offset）不够，因为滞后可能由网络抖动引起；只看bigkey也不行，因为不是所有大Key都会实时影响复制。
- 每10分钟跑一次
redis-cli -h $host -p $port --bigkeys -i 0.01（-i降低采样干扰），结果存入TSDB - 告警规则要联动：当
bigkey_size > 1MB**且**replication_lag > 5000ms同时成立才触发 - 从节点
INFO commandstats中关注cmdstat_hscan调用量突增，可能是拆分任务在运行，需确认是否已收敛
真正麻烦的从来不是发现大Key，而是拆分过程中新老Key并存带来的业务一致性风险——比如读请求还在查旧hash，而写请求已开始更新新shard。这部分必须靠业务层双写+灰度开关控制，Redis本身不提供原子跨Key迁移能力。
