CONFIG SET maxmemory-policy会卡住几秒，是因为Redis在内存超限时需同步阻塞地扫描、采样并淘汰键，该过程耗时与待淘汰键数量正相关，且默认采样5个键，若未命中则反复重试，最坏情况遍历大量键。
不能直接在线切换淘汰策略，必须配合maxmemory重设与业务低峰期操作，否则可能触发批量淘汰导致延迟飙升或连接雪崩。
为什么CONFIG SET maxmemory-policy会卡住几秒？
Redis在执行CONFIG SET maxmemory-policy时，并不会立即重建淘汰逻辑，而是等下一次写命令触发内存检查时才真正生效。但问题在于：如果当前used_memory已经接近或超过maxmemory，新策略一启用，Redis会立刻开始扫描、采样、淘汰——这个过程是同步阻塞的，且耗时与待淘汰键数量正相关。
- 常见现象：
redis-cli CONFIG SET maxmemory-policy volatile-lfu返回后，紧接着SET命令延迟从0.2ms跳到150ms，INFO commandstats里cmdstat_set的usec_per_call明显拉高 - 根本原因：Redis用的是近似LRU/LFU算法，每次淘汰需随机采样
maxmemory-samples个键（默认5），若样本中没找到可淘汰项，会反复采样，最坏情况要遍历大量键 - 更隐蔽的坑：如果旧策略是
noeviction，而你切到allkeys-lru，且此时内存已超限，第一个写命令就会触发强制淘汰，而不是报错
如何避免切策略时出现OOM或延迟抖动？
核心思路是让Redis在切换前先“松一口气”，把used_memory压到安全水位以下，再换策略。这不是靠运气，而是分三步可控操作：
- 先临时调大
maxmemory，比如从4gb升到4.5gb：CONFIG SET maxmemory 4500mb，给内存腾出缓冲空间 - 等1–2分钟，观察
INFO memory里的used_memory是否稳定回落（说明后台过期清理或客户端主动删键起了作用） - 确认
used_memory比新maxmemory低至少10%，再执行CONFIG SET maxmemory-policy volatile-lfu - 最后再把
maxmemory调回原值：CONFIG SET maxmemory 4000mb（这步必须做，否则等于没控内存）
主从架构下切策略要特别注意什么？
策略变更本身不写AOF/RDB，也不走复制流，所以主从的maxmemory-policy配置可能不一致——这是危险信号。
- 主节点切了
volatile-lfu，从节点还是allkeys-lru，一旦发生故障切换，新主节点的行为会突变，缓存命中率可能断崖下跌 - 必须用
CONFIG REWRITE把新策略持久化进redis.conf，然后手动同步配置文件到所有从节点，再逐台执行CONFIG SET - 切完别忘了验证：
redis-cli -h $slave_ip CONFIG GET maxmemory-policy，确保全集群一致 - 如果用哨兵或Cluster，记得更新部署模板或Ansible playbook，否则下次扩缩容又回到老策略
真正难的不是命令怎么敲，而是判断“现在是不是安全切换窗口”——INFO memory里mem_fragmentation_ratio大于1.5、evicted_keys持续归零、expired_keys每秒增长小于100，这三个信号同时满足时，才建议动手。否则宁可多等半小时。
