maxmemory设置过小会导致跨机房同步期间误淘汰，因aof rewrite、全量同步、rdb加载等操作临时推高内存，触发allkeys-lru等策略淘汰正常业务key；需为mem_allocator和used_memory_peak预留至少30%余量，且必须显式设为非零值并落盘。
maxmemory 设置过小会导致跨机房同步期间误淘汰
跨机房同步本身不直接触发淘汰，但会显著增加内存压力：AOF rewrite、主从全量同步（psync）、RDB加载都会临时占用大量内存。如果 maxmemory 设置接近物理内存上限，这些操作极易让 used_memory 瞬间冲破阈值，触发 allkeys-lru 或 volatile-lru 等策略——而此时被淘汰的 key 往往是正常业务缓存，不是同步产生的临时数据。
关键判断点：INFO memory 中的 mem_allocator 和 used_memory_peak 要比 maxmemory 至少预留 30%。例如物理内存 64GB，maxmemory 不建议超过 40GB。
-
maxmemory必须显式设置为非零值，否则淘汰策略根本不会启动，但这也意味着你完全失去内存保护 - 用
CONFIG GET maxmemory验证是否生效；若返回0，说明配置未加载或被覆盖 - 不要依赖
CONFIG SET maxmemory临时调整——重启后丢失，必须写入redis.conf
同步流量突增时 volatile-lru 会误删长期有效 key
很多团队为“安全起见”选 volatile-lru，认为只淘汰带 EXPIRE 的 key。但跨机房同步中，大量中间状态 key（如 Codis slot 迁移标记、Twemproxy 分片路由缓存）也常带 TTL，它们和业务会话 key 混在同一空间里。一旦同步压测开始，这些中间 key 成为 LRU 热点，反向挤掉真正该保留的会话数据。
更危险的是：volatile-lru 在 key 总数少但过期 key 比例高时，淘汰效率反而下降——Redis 会优先扫描过期 key 字典，但实际淘汰仍受限于 maxmemory-samples 抽样数（默认 5），容易漏掉真正冷门的业务 key。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 跨机房场景下，统一用
allkeys-lru比volatile-lru更可控：至少淘汰逻辑覆盖全量 key 空间，避免“分类误伤” - 把中间件/同步组件生成的 key 显式命名隔离，例如加前缀
sync:codis:migration:，方便后续用SCAN清理，而不是靠淘汰机制“碰运气” - 禁用
volatile-ttl：它在同步高峰期可能集中淘汰一批即将过期的 key，导致缓存雪崩式穿透
RDB/AOF 重写与淘汰策略存在隐性竞争
bgrewriteaof 或 save 触发时，Redis 会 fork 子进程。fork 本身不复制物理内存页（写时复制），但一旦父进程触发淘汰，修改 key 的元数据（比如 LRU 时间戳），就会引发页复制，瞬间放大内存占用。这在跨机房同步期间尤为敏感——主节点一边接收同步写入，一边执行 AOF rewrite，used_memory_rss 可能飙升 2～3 倍。
此时即使 maxmemory 有余量，used_memory_rss 超过系统可用内存，OS 可能直接 OOM kill Redis 进程，比淘汰更致命。
- 禁止在同步窗口期内手动触发
BGREWRITEAOF或SAVE；用auto-aof-rewrite-percentage+auto-aof-rewrite-min-size自动控制节奏 - 调低
hz（默认 10）到 5，减少定时任务对内存扫描的干扰；但不能低于 1，否则过期 key 清理延迟加剧 -
maxmemory-samples建议保持默认 5：设太高（如 20）会加重每次淘汰的 CPU 开销，在同步高负载下反而拖慢主循环
集群模式下各分片节点的 maxmemory 必须独立校准
Redis Cluster 或代理分片（如 Codis）中，每个节点内存压力不均。跨机房同步时，通常只有部分节点承担主要同步流量（如靠近源机房的 master 节点），但若所有节点都配相同 maxmemory，下游 slave 节点可能因复制积压迟迟无法释放内存，提前触发淘汰。
真实案例：某集群 16 个分片，其中 3 个分片承载 80% 的同步写入。这 3 个节点 used_memory 常驻 92%，其余节点仅 40%。统一配 maxmemory 16gb 导致那 3 个节点频繁淘汰，而其他节点内存闲置。
- 按节点角色差异化配置：
master节点的maxmemory应比slave高 15%～20%，预留复制缓冲区（repl-backlog-size）空间 - 用
redis-cli --cluster check定期核对各节点maxmemory实际值，避免 conf 文件未同步或 CONFIG SET 覆盖遗漏 - 监控指标必须细化到节点级：
evicted_keys+expired_keys+mem_fragmentation_ratio三者联动看，单看淘汰数容易误判
maxmemory”。这个峰值往往藏在 fork、AOF rewrite、批量导入等后台动作里，而不是业务请求日志中。
