Redis内存满时为什么会拒绝写入？调整maxmemory-policy配置合适的淘汰策略
Redis内存满后拒绝写入的根本原因
当Redis通过maxmemory参数设置了内存上限，且实际使用内存达到此限制时，其行为取决于淘汰策略。若maxmemory-policy配置为noeviction（不淘汰），所有写入命令（如SET、LPUSH）都将被拒绝，并返回OOM command not allowed when used memory > 'maxmemory'错误。
这并非系统异常，而是Redis的核心设计原则：优先保障数据一致性与操作响应确定性。Redis选择明确拒绝写入，而非引入异步淘汰可能带来的延迟与不确定性，确保每次操作的响应都可预测。
哪些maxmemory-policy能避免拒绝写入
要避免内存写满时被拒绝，必须启用具备“主动数据清理”功能的淘汰策略。这些策略会在内存不足时自动移除部分键值对，为新数据腾出空间。选择策略需结合业务数据特点：
allkeys-lru：从全体键中淘汰“最近最少使用”的键。适用于访问模式相对平均、无明显冷热数据之分的通用缓存场景。volatile-lru：仅淘汰设置了过期时间的键。如果你的缓存数据均通过EXPIRE或SETEX管理生命周期，此策略最为匹配。allkeys-lfu：根据键的访问频率进行淘汰，比LRU更能精准识别周期性热点数据。但需维护频率计数器，会带来轻微额外内存开销。volatile-ttl：优先淘汰剩余生存时间最短的键。适用于延迟队列、时效性缓存等具有明确时间层级的数据结构。
特别注意：noeviction（默认策略）会直接拒绝所有写入；而allkeys-random和volatile-random虽会随机删除键，但因淘汰行为不可控，生产环境极少采用。
调整策略前必须确认的三件事
修改maxmemory-policy配置前，务必核实以下关键点，避免配置失效或引发意外：
- 核实键的过期时间设置：若选择
volatile-*系列策略（如volatile-lru），必须确保大部分键已通过EXPIRE设置了过期时间。否则“可淘汰池”为空，策略将无法生效，最终仍会触发写入拒绝。 - 监控淘汰是否真实发生：配置变更后，需通过
INFO memory命令持续观察evicted_keys指标。若该值长期为零，可能意味着淘汰条件未触发，或策略未正确生效。 - 关注LFU策略的精度参数：若选用LFU策略，需留意
lfu-log-factor（对数因子）和lfu-decay-time（衰减时间）两个参数。它们控制访问频率的计数精度与衰减速度，在访问极低频的场景下，不当配置可能导致淘汰逻辑失效。
线上调整策略的安全操作顺序
在生产环境变更Redis淘汰策略，应遵循严谨的操作流程，以规避风险：
- 第一步：记录当前状态。使用
CONFIG GET maxmemory-policy与INFO memory记录原有策略及内存使用基线数据。 - 第二步：做好数据准备。若从
noeviction切换至volatile-lru等策略，需提前确保至少70%的键已设置合理的过期时间，避免策略因无可淘汰键而失效。 - 第三步：变更并实时监控。通过
CONFIG SET maxmemory-policy动态调整后，立即监控evicted_keys（淘汰键数）与used_memory_peak_human（内存峰值）等核心指标。若5分钟内无变化，需检查配置是否生效或数据是否符合淘汰条件。 - 第四步：持久化配置。确认新策略运行稳定后，务必将其写入
redis.conf配置文件，并规划重启以使配置永久生效，防止实例重启后回退至默认的noeviction策略。
最后需明确：内存淘汰策略仅是缓解内存压力的临时方案，治标不治本。更应持续关注内存增长的根源，如内存分配器（mem_allocator）效率、是否存在大对象（BigKey）堆积、客户端连接泄漏等深层系统状态，从源头优化内存使用。
