运行中改上限立即生效
运行中调整内存上限会立刻生效，两个方向的后果并不对称：调低可能马上触发大批淘汰，或者让写命令开始报错；调高只会放宽上限，不会把已经淘汰掉的数据找回来。所以这一步要按变更流程走：先看当前用量与淘汰策略，再执行修改，然后在随后几分钟里盯着淘汰计数与内存曲线，确认没有出现集中淘汰。
基本信息
| 修改方式 | 运行时配置命令，立即生效 |
|---|---|
| 调低的后果 | 可能触发批量淘汰或写请求被拒 |
| 调高的后果 | 仅放宽上限，不恢复已淘汰数据 |
| 观察指标 | 淘汰计数、过期计数与内存曲线 |
| 执行要求 | 纳入变更流程并保留操作记录 |
典型使用场景
- 扩容前临时放宽上限，缓解内存吃紧导致的写入报错
- 缩容机器前先降低上限，观察业务在更小内存下的表现
- 排查内存告警时核对当前配置与用量是否匹配
- 演练中验证不同上限下淘汰策略的实际行为
- 容量评审后把新上限写回配置文件，避免重启后回退
调整示例
调整示例
redis-cli CONFIG GET maxmemory maxmemory-policy # 先看现状
redis-cli INFO memory | grep -E 'used_memory:|maxmemory' # 当前用量与上限
redis-cli CONFIG SET maxmemory 4gb # 调高上限
redis-cli INFO stats | grep -E 'evicted_keys' # 观察是否出现淘汰
redis-cli CONFIG REWRITE # 写回配置文件持久生效动作与影响
| 动作 | 立即影响 | 必须观察 |
|---|---|---|
| 调低上限 | 可能触发批量淘汰或写请求报错 | 淘汰计数增速与业务报错 |
| 调高上限 | 放宽限制，写入恢复正常 | 内存曲线是否继续上涨 |
| 上限设为 0 | 视为不限制，风险很高 | 容器或系统层是否会直接杀掉进程 |
| 未写回配置文件 | 重启后回到旧值 | 重启前后行为一致性 |
调低上限之前先估算当前用量与目标值的差距，差距越大越可能触发集中淘汰，业务侧要提前做好准备。
调高上限只是缓解手段，同时要更新容量规划，否则增长趋势被掩盖，下一次告警会更晚更急。