版本说明

本文写于 2022-03。
本文所涉核心配置项在 Redis 6.x/7.x 上含义未变，经 2026-07 复核仍适用；7.0 起新增了部分与 ACL、Function 相关的配置项，本文未涉及。

1. redis.conf 改错一个参数，为什么整个集群会雪崩

生产上最容易踩的坑不是"不会用 Redis"，而是"改了 redis.conf 里一个看起来无关紧要的参数，结果实例被 OOM killer 干掉，或者主从复制悄悄断了却没人发现"。redis.conf 里近 200 个配置项，真正需要盯紧的不到 20 个，但这 20 个每一个都能决定"服务正常"还是"数据丢了/进程没了"。本文按功能分组，只讲会实际影响生产结果的参数。

2. 为什么不能全部用默认值

Redis 的默认配置是为"能跑起来"设计的，不是为"生产安全"设计的。典型的默认值陷阱：

• maxmemory 默认 0（不限制）——内存会一直涨到把宿主机 OOM，可能连带把其他服务一起打死。
• appendonly 默认 no——一旦进程被 kill，未持久化的数据全部丢失。
• protected-mode 虽然默认开启，但只要绑了非 127.0.0.1 的地址且没设密码，等于对公网/内网敞开。
• save 默认有一组 RDB 快照策略，但很多人图省事直接注释掉，等于放弃了灾难恢复的最后一道保险。

3. 分组解读：准备 → 执行 → 验证

3.1 网络与安全

bind 127.0.0.1 -::1        # 只监听指定网卡，不要写 0.0.0.0
protected-mode yes         # 无密码时拒绝非本地连接
port 6379
requirepass <strong-password>

验证：

redis-cli -h 127.0.0.1 -p 6379 ping
# 未认证应返回：(error) NOAUTH Authentication required.
redis-cli -h 127.0.0.1 -p 6379 -a <strong-password> ping
# 应返回：PONG

3.2 内存与淘汰策略

maxmemory 4gb
maxmemory-policy allkeys-lru   # 缓存场景常用；纯存储场景用 noeviction

maxmemory-policy 决定内存打满后的行为，选错的后果完全不同：

策略	行为	适用场景
noeviction	拒绝写入，报错 OOM command not allowed	数据库/队列，不允许丢数据
allkeys-lru	淘汰最近最少使用的 key（不管有无过期时间）	纯缓存
volatile-lru	只在设置了过期时间的 key 里做 LRU 淘汰	缓存与持久数据混用
allkeys-random	随机淘汰	访问模式无局部性时

验证：

redis-cli config get maxmemory-policy
redis-cli info memory | grep used_memory_human

3.3 持久化：RDB 与 AOF

save 900 1
save 300 10
save 60 10000

appendonly yes
appendfsync everysec       # 折中：每秒 fsync 一次，最多丢 1 秒数据

• save 三行是 RDB 快照触发条件，格式为"N 秒内至少 M 次写操作则触发快照"，三条可以叠加。
• appendfsync always 最安全但性能最差（每次写都 fsync）；no 性能最好但依赖操作系统刷盘时机，最不安全。everysec 是绝大多数场景的正确选择。

验证：

redis-cli config get save
redis-cli config get appendonly
ls -la /var/lib/redis/*.rdb /var/lib/redis/appendonlydir/ 2>/dev/null

3.4 慢查询与连接数

slowlog-log-slower-than 10000   # 微秒，10ms 以上记录
slowlog-max-len 1000
maxclients 10000
timeout 300                     # 客户端空闲超时（秒），0 为不超时

验证：

redis-cli config get slowlog-log-slower-than
redis-cli slowlog get 10

4. 常见坑

症状：Redis 进程在业务高峰期被系统杀掉，dmesg 里能看到 Out of memory: Killed process。 原因：maxmemory 未设置或设置过大，加上系统开启了内存 overcommit，Redis fork 子进程做 RDB/AOF 重写时瞬时内存翻倍，触碰宿主机物理内存上限。 解药：sysctl vm.overcommit_memory=1（允许过量分配，避免 fork 失败）；同时把 maxmemory 设为宿主机内存的 60%-70%，留出 fork 重写时的缓冲。

症状：主从复制正常运行数天后突然断开，从库日志报 MASTER <-> REPLICA sync error。 原因：repl-backlog-size 太小，主库写入量大时从库短暂断连（网络抖动）重连后想做增量同步，但积压缓冲区已经被覆盖，只能被迫全量重同步；如果全量同步耗时超过 repl-timeout，会反复失败。 解药：把 repl-backlog-size 调到能覆盖"从库断连到重连"这段时间内的写入量（一般 100mb 起步），并适当调大 repl-timeout。

症状：CONFIG SET 改了参数立即生效，但重启后又变回旧值。 原因：CONFIG SET 只改运行时内存中的配置，不会写回 redis.conf 文件。 解药：改完用 CONFIG REWRITE 把当前运行配置持久化回配置文件，或者直接改配置文件再 SIGHUP/重启。

5. 可复用的规则

1. 网络与内存这两组参数必须在上线前就定好——bind/requirepass/maxmemory/maxmemory-policy，不要用默认值跑生产。
2. 持久化策略的选择本质是"丢多少数据可接受"和"写入性能"之间的权衡，先想清楚业务能容忍的数据丢失窗口，再选 appendfsync 档位。
3. CONFIG SET 是运行时热更新，配套 CONFIG REWRITE 才能持久化，两者要一起记。
4. 主从环境下 repl-backlog-size 必须按"最大可能的重连间隔 × 写入速率"来估算，不能用默认值。

6. 延伸阅读

Redis 常用操作与数据结构命令见 Redis 安装配置与常用操作；分布式场景下的槽位分配见 Redis 槽位 slot 解读。

---

7. Agent 可直接解析的元数据块

{
  "_meta": {
    "doc_version": "2026-07-29",
    "article_id": "redis-conf-explained",
    "profile_context": "any",
    "estimated_setup_time": "15min"
  },
  "quick_start": {
    "step_1": "grep -E '^(bind|requirepass|maxmemory|appendonly)' /etc/redis/redis.conf",
    "step_2": "redis-cli config get maxmemory-policy",
    "step_3": "redis-cli config set appendfsync everysec && redis-cli config rewrite"
  },
  "safety_rules": [
    "生产环境禁止 bind 0.0.0.0 且不设 requirepass",
    "修改 maxmemory-policy 前先确认业务能否接受数据被淘汰",
    "CONFIG SET 后必须 CONFIG REWRITE 才能持久化，否则重启失效"
  ],
  "verification": {
    "check_auth": "redis-cli -a <password> ping 应返回 PONG",
    "check_persistence": "ls appendonlydir/ 或 *.rdb 确认持久化文件存在且时间戳更新",
    "check_replication": "redis-cli info replication 查看 master_repl_offset 与从库是否一致"
  }
}

AI Agent 使用指南：

• 当用户说"帮我检查 Redis 配置是否安全" → 依次执行 quick_start 三步，并核对 safety_rules
• 当用户说"主从同步老是断" → 检查 repl-backlog-size 与 repl-timeout，参考第 4 节坑位