Redis 配置热修改：一条 CONFIG SET 顶住了快满的缓存

写在前面：这篇是给收到 Redis 内存告警, 又不敢轻易重启的兄弟写的。CONFIG SET 能救命, 但救的是当下的急, 不是根上的病。

有天收到一条内存告警。

Redis 的 maxmemory 当初设得保守, 只给到整机内存的 70%, 现在用量爬到了 95%, 眼看就顶满了。我一个人对着监控面板, 第一反应是改maxmemory。可刚想改的时候就想到一个严重的问题——配置写在 redis.conf 里, 改完得重启才生效。

为什么之前那套不行

Redis 的常规配置在 redis.conf 里, 改完得重启生效。而我们的应用场景——Redis 全都没开持久化。

没开持久化意味着: 重启一次, 内存里的数据全清空。用户登录态全失效, 得重新登录; 一堆缓存瞬间蒸发, 请求直接砸到数据库上。

所以能走的路其实就三条, 没一条轻松：

重启改配置 —— 配置是改对了, 但数据全清空, 登录失效加缓存雪崩, 数据库被打爆, 回填能忙活半天。
只改配置文件不重启 —— 以为生效了, 实际纹丝没动; 而一旦被迫重启, 数据照样没, 两头不靠。
直接 CONFIG SET 不改文件 —— 当晚会顶住, 但配置没落盘; 哪天 Redis 因为任何原因重启, 数据清空不说, maxmemory 还退回原值, 95% 的雷原样埋回去。

这三条我都替你试过了。结论是：前两条要么断业务, 要么骗自己；第三条能救急, 但得补一刀才稳。

我的解法：先看清, 再热改, 最后落盘

后来才想起来, Redis 自带 CONFIG SET, 不用重启就能改运行参数。流程其实就三步, 但顺序不能乱：

第一步, 先看现状, 别凭记忆手抖。


Bash
CONFIG GET maxmemory
CONFIG GET maxclients
CONFIG GET appendonly

CONFIG GET * 能把所有配置一股脑倒出来, 像一份全景地图。真要查单项, 就别用 *, 浪费眼。

第二步, 热修改, 一条命令顶上去。


Bash
# 内存快爆了, 从保守的 70% 提到 85%(这台机器即 435G), 留 15% 给系统和别的进程
CONFIG SET maxmemory 435g

# 连接数被打满, 临时放开
CONFIG SET maxclients 1000

# 日志太吵, 调成 warning
CONFIG SET loglevel "warning"

第三步, 也是最容易忘的一步：改配置文件。

CONFIG SET 只改内存里的运行实例, 重启就还原。所以改完必须顺手把 redis.conf 里对应那行也改了, 否则——你猜怎么着, 就是上面第三条的老剧本。

这一分钟发生了什么

那天从收到报警到改完, 大概一分钟。

以我这台 512G 的机器算笔账: maxmemory 原来按保守的 70% 设成 358G, 已经用掉 95%(约 340G, 占整机 66.5%)。把 maxmemory 提到 85%(435G), 同样 340G 的数据, 占用率就从 95% 掉到约 78%——绝对值多出约 77G(整机 15%)的缓冲带, 关键是不再贴着淘汰线走。落到命令就是 CONFIG SET maxmemory 435g, 全程没重启, 数据一个没丢, 业务零中断。报警停了, 我也踏实了。

热修改是止血, 不是治病。 这句话我写在便签上, 贴显示器边上了。

泼个冷水：

说几句实在话, 别被"热修改"三个字忽悠了：

不是所有配置都能热改。 cluster-config-file 这类跟集群配置文件路径相关的, 改不了, 强改只会报错。动之前先查官方文档确认支持不支持。
热改不持久, 重启打回原形。 这是设计如此, 不是 bug。所以"改完就走人"是新手最容易栽的坑。
maxmemory 只能加不能减, 改之前先看剩余内存。 得留足余量——设得太靠近物理内存, 进程直接被 OOM killer 干掉。我这台 512G 的机器提到 435G, 还留着 77G, 就是故意不把内存吃满。
持久化参数改猛了, 性能掉一截。 把 appendfsync 从 everysec 改成 always, 数据安全是上去了, 磁盘 I/O 也上去了, 写入吞吐当场打折。