主库内存上涨与从库同步延迟增大通常源于复制积压缓冲区被撑满及冷数据未及时清理：① rdb生成致内存峰值翻倍；② 从库加载rdb时无法处理新命令；③ replica-serve-stale-data no导致读拒绝。
主库内存持续上涨，INFO replication 显示从库同步延迟增大
这通常不是单纯“写入太多”的问题，而是主库在向从库全量同步（SYNC 或 PSYNC）时，复制积压缓冲区（repl-backlog）被撑满，同时大量冷数据未过期，导致：
① 主库 RDB 生成时内存峰值翻倍；② 从库加载 RDB 阶段无法接收新命令，主库积压更多待同步命令；③ replica-serve-stale-data no 下从库拒绝读请求，业务误以为故障。
EXPIRE 和 EXPIREAT 不是万能的——冷数据得靠主动识别
Redis 不会自动标记“冷数据”，EXPIRE 必须由业务显式设置。常见误区是只在写入时加固定 TTL（比如一律 EXPIRE key 3600），但实际访问模式差异大：用户 session 可能 10 分钟就失效，而商品缓存可能需保留 2 小时但实际 20 分钟后就再没被读过。
- 优先用
SCAN+OBJECT IDLETIME批量识别长期未访问的 key（注意：仅限非 volatile key，且IDLETIME在集群模式下不可靠） - 对带业务语义的 key（如
user:123:token、cache:product:456），在写入时直接绑定动态 TTL：例如登录 token 过期时间 = 当前时间 + 用户活跃窗口，而非硬编码 3600 - 避免在高并发写路径中调用
OBJECT IDLETIME，它会阻塞单线程，应放在低峰期定时任务里跑
复制积压缓冲区（repl-backlog）大小必须匹配冷数据清理节奏
如果每小时清理 5GB 冷数据，但 repl-backlog-size 只设了 100MB，主库一旦触发 PSYNC 失败降级为全量同步，就会反复重传这 5GB 中已过期却尚未被释放的 key —— 它们仍存在于 RDB 快照里，直到下次 SAVE 或 BGSAVE。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
CONFIG GET repl-backlog-size查当前值，生产环境建议 ≥ 主库 10 分钟内写入的平均数据量（可从INFO stats的total_commands_processed和 key 平均大小估算） - 清理冷数据后，立刻执行
BGREWRITEAOF（如果启用了 AOF）或等待下一次BGSAVE，确保过期 key 不再进入新 RDB - 禁用
activedefrag yes在内存紧张时自动整理碎片——它会加剧主库 CPU 和内存压力，与同步冲突
从库不能只靠 slave-read-only yes 就高枕无忧
即使从库设为只读，主库仍在把所有写命令（包括 DEL、EXPIRE、UNLINK）发给它。如果主库批量清理冷数据用的是 DEL（阻塞式删除），从库在重放这些命令时也会卡住，进一步拉大延迟。
- 主库清理冷数据务必用
UNLINK替代DEL，它把实际内存释放交给后台线程，不阻塞同步流 - 检查从库日志是否频繁出现
Sync with master failed: Connection reset by peer—— 这往往是因为主库在BGSAVE期间 fork 失败（内存不足），而根本原因就是冷数据没及时释放 - 监控项要补上：
mem_allocator（确认是否 jemalloc）、evicted_keys（是否已触发 LRU 驱逐）、expired_keys（过期 key 实际清理速率）
真正难的不是加 EXPIRE，而是让过期时间和数据真实生命周期对齐；也不是调大 repl-backlog-size，而是确保这个缓冲区里塞进去的命令，不会反复搬运一批早就该消失的数据。
