拿到一台陌生的 Redis 服务器大多数人习惯性敲一句redis-server就完事配置文件先放着不管。这个做法在本地开发环境能跑可一旦上了生产内存被写满、主从同步失败、重启后数据全部丢失再回头翻 redis.conf才会发现里面每一行默认值的背后都是对你的业务到底适合哪种运行方式的考验。这篇文章不打算把官方文档重新翻译一遍而是从一个实际维护过 Redis 实例的开发者视角把 redis.conf 里最关键的配置项、它们之所以存在的理由、以及我在操作中踩过的坑一条一条讲明白。无论你是刚接触 Redis还是已经在生产环境背过锅这份配置清单应该都能帮你少走几次弯路。1. redis.conf 的加载链路启动参数、配置文件与 CONFIG 命令谁说了算1.1 配置文件在 Redis 中的真实位置Redis 的配置来源一共有三个启动命令行参数、redis.conf 配置文件、以及运行时的CONFIG SET命令。这三者的优先级并不是后写入的覆盖先写入的这么简单得把加载顺序理清楚。正常情况下Redis 启动时只会加载你指定的那个配置文件路径靠启动参数传入redis-server /path/to/redis.conf如果你不带配置文件直接redis-server那就等于让 Redis 用内置默认值运行文件系统里那份 redis.conf 根本不会参与。这一点看起来稀松平常却是很多人改完配置发现不生效的第一大原因——你改的文件和进程实际加载的文件压根不是同一个。在 Linux 发行版中通过 systemd 或 service 方式启动 Redis配置路径通常写在启动脚本里比如/etc/redis/redis.conf。但如果你是手动编译安装的默认 conf 会在源码目录里稍微不小心就会用redis-server --daemonize yes直接跑从而绕过了配置文件。1.2 include 指令与配置加载顺序redis.conf 支持include指令用来引入其他配置文件比如把不同环境的通用配置拆出来放一份环境差异配置放另一份include /etc/redis/redis-local.conf include /etc/redis/redis-memory.conf关于 include 有两个细节很重要。第一include指令所在的位置决定了被引入文件的优先级——如果某个参数在主文件中已经写在 include 之前那么 include 引入的文件会覆盖它反之则被覆盖。所以不要让主文件和被 include 文件里出现同一个参数的重复定义这种谁后来谁生效的逻辑很容易在排查问题时把人绕晕。第二CONFIG REWRITE重写配置文件时include 进来的内容不会被展开写回主文件Redis 只会重写主文件里非 include 引入的配置段。1.3 用 CONFIG GET 验证当前生效值改配置前第一步永远是先确认当前进程实际加载了哪些参数。Redis 提供了运行时查询接口redis-cli CONFIG GET save redis-cli CONFIG GET maxmemory redis-cli CONFIG GET dir这几个命令会直接返回进程内正在生效的值不用猜也不用翻启动脚本。我个人的习惯是接手任何一台 Redis 机器第一件事就是CONFIG GET *拉一份全景配置和手头的 redis.conf 逐项比对。很多时候配置没生效的真相是启动命令后面带了--maxmemory 512mb这样的临时参数优先级高于配置文件而且进程不重启就一直在。2. 内存配置是命门maxmemory 与逐出策略选型2.1 为什么默认配置在线上必翻车Redis 64 位版本默认的maxmemory是 0表示不限制内存使用。这在开发环境很友好因为怎么写入都不会触发内存淘汰。但线上跑几个月后内存会被各种缓存数据、消息队列积压、计数器和会话数据逐步填满最终触发操作系统层面的内存压力甚至让 Redis 进程被 OOM Killer 干掉。即使你给 Redis 所在的机器配了 64GB 内存只要 maxmemory 没设置Redis 就会一直用直到用完物理内存。另一个容易被忽略的问题是Redis 自身还有复制缓冲区、客户端输出缓冲区、AOF 重写缓冲区的额外内存开销这些都不在 maxmemory 统计范围内。所以保守的做法是maxmemory 设置为机器物理内存的 50% 到 60%留出给操作系统页缓存和其他进程的空间。2.2 maxmemory-policy八种逐出策略怎么选当内存达到 maxmemory 上限后写入命令能否继续执行取决于maxmemory-policy。Redis 提供了八种策略我在这里整理成一张对比表方便随时查阅策略作用范围行为noeviction全局不逐出任何 key写入直接报错allkeys-lru全局按近似 LRU 淘汰最久未使用的 keyvolatile-lru仅限设置了过期时间的 key按近似 LRU 淘汰最久未使用的 keyallkeys-random全局随机淘汰任意 keyvolatile-random仅限设置了过期时间的 key随机淘汰volatile-ttl仅限设置了过期时间的 key优先淘汰剩余 TTL 最短的 keyallkeys-lfu全局按访问频率淘汰最不常用的 keyvolatile-lfu仅限设置了过期时间的 key按访问频率淘汰最不常用的 key很多刚接触 Redis 的人以为设置了过期时间的 key 会在到期那一刻被立刻删除所以线上选择volatile-lru就安全了。实际上 Redis 对过期 key 的清理是惰性删除 定期抽样删除配合完成的并不会盯住每个 key 的倒计时。当 maxmemory 耗尽触发逐出时volatile-*系列策略只会扫描那些设置了 TTL 的 key如果你大量 key 都没有设置过期时间那这些 key 就不会被淘汰写入依旧会报错内存问题没有根本解决。2.3 LRU 还是 LFU从实际访问模式出发Redis 4.0 之后引入了 LFULeast Frequently Used策略通过统计访问频率来判断哪些数据更热。它适合稳定存在二八现象的访问场景即少量高频 key 贡献了绝大多数访问量而绝大部分 key 属于偶尔访问的冷数据。这种场景下LFU 比 LRU 更不容易误杀热点 key。反过来说如果你的访问模式是周期性的、短时间集中访问一批 key一阵子之后这批 key 又被新的一批替代那 LRU 更合适因为 LFU 会给旧热点积累过高的频率计数导致它们在数据变冷后仍然不容易被逐出。maxmemory-samples默认是 5它控制逐出时的采样数量。Redis 的 LRU 是近似 LRU并不是全量扫描所有 key 找出最久未用的那个而是随机采样 N 个 key再从样本里淘汰符合条件的。这个值调大逐出结果会更精确但每次逐出的 CPU 开销也会提高。日常运行不需要动线上如果追求更准确的淘汰效果可以提高到 10 到 20不建议超过 20否则 LCPU 消耗在 LRU 比较上不值。2.4 逐出机制的两个易踩点第一maxmemory的修改是动态的。如果你用CONFIG SET maxmemory 256mb把上限从 1GB 降到了 256MB而当前内存已经用了 800MBRedis 会立刻开始逐出 key直到内存降到 256MB 以下。这个行为在业务高峰时做很可能让大量缓存瞬间失效引发缓存雪崩。第二逐出不等于删除过期 key不要混淆这两个概念。逐出是 Redis 在内存压力下的主动清理它会选择策略允许的 key 进行删除哪怕这个 key 其实还很新鲜。所以在使用allkeys-lru的缓存场景里如果某个 key 被淘汰后下一次访问会引发昂贵的后端查询那它的重要程度就需要单独评估要么把它放到另一个不用作缓存淘汰的 Redis 实例里要么通过volatile-*策略配合 TTL 单独控制。3. RDB 与 AOF 的取舍持久化配置里的数据安全账3.1 RDB 快照save 参数与 fork 机制RDB 是 Redis 默认的持久化方式通过周期性生成内存快照来保存数据。redis.conf 里的默认配置是save 900 1 save 300 10 save 60 10000每一行的含义是在指定秒数内如果发生至少指定次数的写操作就触发一次快照。900 秒内有 1 次写、300 秒内有 10 次写、60 秒内有 10000 次写三个条件只要满足任意一个就会执行 bgsave。stop-writes-on-bgsave-error默认是 yes意思是如果后台保存失败Redis 会停止接收写入命令。这个参数很值得关注。我见过一台磁盘空间打满的机器RDB 持续写不进去结果 Redis 对业务直接只读所有写入请求全部报错。如果业务可以接受短暂丢失一部分更新而更看重写入的连续性可以考虑把这个值设为 no但前提是你明确知道磁盘故障期间如果进程崩溃数据会丢多少。RDB 的底层机制是 fork 一个子进程来生成快照父进程继续响应外部请求。因为 fork 之后利用操作系统的 copy-on-write 特性父进程后续的修改不会影响子进程正在生成的快照。代价是fork 瞬间如果实例内存很大比如几十 GB会产生一轮短暂的停顿这个停顿时间可能从几百毫秒到数秒不等。3.2 AOF 日志appendfsync 的三种策略对比AOF 通过追加每次写命令到日志文件来保证更高的数据安全性。开启方式appendonly yes appendfilename appendonly.aof真正影响数据安全与性能平衡的是appendfsync可选值只有三个值行为数据安全性性能影响always每次写命令都同步刷盘最高最多丢一个写命令明显降低写吞吐everysec每秒同步一次最多丢 1 秒内的写入性能影响较小no交给操作系统决定刷盘时机可能丢多秒的写入性能最好生产环境里everysec是绝大多数场景的默认选择。它几乎不影响正常写入性能又能在进程异常退出时把数据损失控制在 1 秒以内。always适合对数据完整性要求极高的场景比如交易流水、订单状态但你要能接受写入吞吐的明显下降。no基本不推荐因为进程宕机时丢多少数据完全不可控省下来的那点性能通常不值得。需要提醒一点AOF 文件会随着运行无限增长Redis 提供了重写机制auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb当 AOF 文件体积比上一次重写后的体积增长了 100%并且文件大小超过 64MBRedis 会自动触发重写。重写不是对旧文件做追加截断而是把当前内存里的数据重新生成一套最小的写命令集合写到一个临时文件里再原子替换。实际使用中如果你的写模式是频繁更新同一个 keyAOF 重写会非常有效能把几十 GB 的日志压回几百 MB。3.3 混合持久化别忽略 aof-use-rdb-preambleRedis 4.0 之后默认开启aof-use-rdb-preamble yes它允许 AOF 文件开头直接放一段 RDB 格式的内存快照后面再追加增量写命令。这样做的最大优势是启动恢复速度快——加载 headers 处的 RDB 快照几乎瞬间完成只需要重放后面一小段增量命令而不是把整个 AOF 文件从头到尾执行一遍。如果你还在用纯 AOF 模式一个几十 GB 的日志文件在实例重启后可能要花上一两分钟甚至更长时间才能恢复完期间 Redis 对外完全不可用。混合持久化把这个时间缩短到十几秒级别。线上建议保持默认开启。3.4 持久化参数丢失的排查案例我遇到过一起数据丢得莫名其妙的事故。业务反馈凌晨某段时间写入的数据早上重启 Redis 后消失了一半。排查后发现RDB 的 save 条件是 60 秒 10000 次写凌晨低峰期写入量远达不到这个阈值上一份 RDB 是一个多小时前的AOF 又没有开启所以重启后直接加载了那份旧快照。这个案例其实是在提醒RDB 只有在满足 save 条件时才会更新低写入量阶段数据缺口可能非常宽。如果业务不允许重启后丢这么多数据要么开启 AOF要么调低 save 阈值要么主从同时部署并用从库做恢复。4. 从本机到内网bind、认证与 ACL 的网络边界管理4.1 bind 与 protected-mode 的配合逻辑Redis 默认监听 127.0.0.1也就是只有本机可以访问。如果想让内网其他机器连上来需要修改bind配置。最常见的几个写法bind 127.0.0.1 -::1 bind 192.168.1.100 127.0.0.1 bind 0.0.0.0bind 0.0.0.0表示监听所有网卡这是最省事也最危险的写法。Redis 的protected-mode默认是 yes它和 bind 有个联动关系如果 bind 只配了 127.0.0.1那么 protected-mode 生效一旦你手动 bind 了具体内网 IP 或者 0.0.0.0protected-mode 就会让位于更明确的网络绑定意图。有一个细节经常被忽略即使把 bind 改成内网 IP如果同时设置了requirepass或 ACL那么未认证的连接仍然无法执行任何命令这算是一道兜底防线。但如果你既没有设置密码又把 bind 暴露在公网网卡上Redis 就处在裸奔状态扫描工具很快就会发现并尝试写入定时任务。4.2 requirepass 与 ACL 用户体系requirepass是最传统的密码认证方式requirepass your_strong_password设置之后客户端连接需要先执行AUTH your_strong_password才能操作。要注意的是requirepass一旦通过CONFIG SET在线修改不会影响到已经建立的连接但新连接会立刻使用新密码。这个当前连接不受影响的特性偶尔会造成困惑明明改了密码老的连接还能读写看起来像没生效。Redis 6.0 之后引入了 ACL比单个密码灵活得多。比如配置一个只能访问特定 key 前缀的只读用户user readonly on readonly_pwd ~cache:* get mget exists这段配置的含义是创建一个名为 readonly 的用户启用状态密码是 readonly_pwd只能访问 key 前缀为cache:的命令并且只允许执行 get、mget、exists。这种最小权限的配置方式适合给不同业务模块分配独立的 Redis 访问账号避免一个 key 被其他模块误删。4.3 危险命令的禁用思路rename-command允许把危险命令重命名或直接禁掉rename-command FLUSHALL rename-command KEYS rename-command CONFIG 命令名设置为空字符串等于完全禁用。这个配置对生产环境很有意义尤其是KEYS命令它会在全库扫描 key数据量大时直接卡死 Redis。需要模糊匹配 key 的时候应该改用SCAN命令配合游标迭代或者维护一个索引 key。5. 性能参数不是越多越好真正值得动手的几个配置项5.1 client-output-buffer-limit主从全量同步时最容易爆掉的缓冲区默认配置里有一行很容易被忽略client-output-buffer-limit normal 0 0 0 client-output-buffer-limit replica 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60这组参数控制不同客户端类型的输出缓冲区上限。第一个normal是普通客户端默认不限制第二个replica是主从复制场景下的从库连接256MB 是硬性上限64MB 是软性上限持续 60 秒超过软上限会被断开第三个pubsub是发布订阅客户端。主从全量同步时主库需要把 RDB 快照和后续增量命令都发给从库如果从库处理速度跟不上主库那边的输出缓冲区就会不断膨胀。一旦超过replica限制主库会断开这个从库连接从库只能重新发起全量同步这就形成了一个恶性循环。我当时遇到的情况是从库机器磁盘性能太差RDB 加载很慢主库等不及就把连接断了反复重试主库网络和磁盘都被拖垮。解决方案是把replica缓冲区的软上限调高同时给从库换性能更好的磁盘。5.2 slowlog 慢日志定位延迟的第一入口slowlog-log-slower-than 10000 slowlog-max-len 128slowlog-log-slower-than的单位是微秒默认 10000 微秒也就是超过 10 毫秒的命令会被记录到慢日志。slowlog-max-len表示内存中最多保存多少条慢日志超出后最早的会被丢弃。慢日志排查命令延迟非常有用尤其是当 Redis 的 QPS 很高、却总有些命令用时异常时。你可以通过redis-cli slowlog get 20直接查看最近 20 条慢日志里面记录了命令执行时间、耗时、客户端 IP 和命令内容。如果发现大量 DEL 大 key、KEYS、SORT 这类耗时命令基本就能定位到延迟来源。5.3 数据编码参数小对象的隐形内存优化Redis 对一些小体积数据对象会采用特殊编码以降低内存开销。相关参数在 7.0 后叫法有所调整hash-max-listpack-entries 128 hash-max-listpack-value 64 set-max-intset-entries 512 zset-max-listpack-entries 128 zset-max-listpack-value 64简单说当哈希、集合、有序集合的元素数量不多且每个元素体积较小时Redis 会用紧凑的 listpack 或 intset 编码存储而不是直接使用标准数据结构。这个设计能让内存占用大幅下降。例如一个包含几百个整数元素的 Set用 intset 编码比用标准哈希表省出的空间相当可观。这些参数通常不需要优化因为默认值已经覆盖了绝大多数场景。但如果你存储大量小体积对象可以适当调大hash-max-listpack-entries比如从 128 调到 512让更多的小哈希保持紧凑编码。要注意的是编码转换是单向的——一旦某个哈希的元素数量超过上限它会被提升为普通哈希结构之后即使元素减少也不会自动转回 listpack。所以不要因为短期的数据波动反复调整这个阈值。5.4 不值得乱动的网红参数网上很多 Redis 优化文章会建议改tcp-backlog、hz这些参数。tcp-backlog默认 511控制的是 TCP 连接的等待队列长度除非你确认短时间内有大量并发连接排队否则一般不需要动。hz默认 10它决定 Redis 每秒执行后台任务的频率调高可以加快过期间歇清理和逐出的响应速度但也会增加 CPU 开销。对绝大多数应用来说这两个参数保持默认即可调了半天性能提升也感知不到反而增加了配置维护的复杂度。6. 修改配置的正确姿势在线改、rewrite 与重启的边界6.1 CONFIG SET 与 CONFIG REWRITE 的分工Redis 允许通过CONFIG SET在线修改部分参数不需要重启。例如redis-cli CONFIG SET maxmemory 1gb redis-cli CONFIG SET appendonly yes但这里有一个关键认知CONFIG SET修改的是当前进程的运行参数并不会自动写回 redis.conf。如果之后你重启 Redis这些在线修改全部失效一切以文件内容为准。这也就是重启之后配置还原的最常见原因。让在线修改持久化需要执行CONFIG REWRITEredis-cli CONFIG REWRITE这个命令会把当前进程生效的配置写回 redis.conf重写文件时会保留原有的注释和 include 结构并把与默认值不同的参数更新进去。我在实际操作中见到过有人频繁执行CONFIG SET之后忘了 rewrite结果一次机房断电重启所有调优参数全部回到旧状态。6.2 哪些参数可以在线改哪些必须改文件大部分内存、网络、安全相关的参数都支持在线修改比如 maxmemory、maxmemory-policy、appendonly、requirepass、slowlog-log-slower-than。但有些参数不行比如bind、port、daemonize、dir这些和进程启动环境强相关的配置必须在配置文件中修改并重启后生效。以bind为例它是监听 socket 时就要确定的属性运行时改没有意义。requirepass可以运行时改但注意新密码是立刻对新的连接生效的不要在一个正在承载线上流量的实例上贸然修改最好提前规划好切换时间窗。6.3 防翻车清单改配置前必查的五个点在线修改参数看似方便但翻车的概率一点不低。我列一份自查清单修改maxmemory前先确认当前已用内存是否高于新上限避免触发大规模逐出。修改appendfsync为 always 前评估写吞吐下降是否在可接受范围。修改requirepass后确认已有客户端使用的账号密码是否需要同步更新别把业务连接全部踢掉。执行CONFIG REWRITE前确认配置文件所在目录可写否则会报错且不会写入。任何修改都要和团队成员同步特别是多人共同维护的 Redis 实例避免你改完了他不知道下次他重启把配置还原到旧版本。7. 一份可以复制的配置基线模板讲完这么多最后给出一份我实际用在中等规模缓存场景的配置基线它兼顾了数据安全、内存保护和日常运维便利可以作为起步模板再按业务调整# 网络访问边界 bind 0.0.0.0 protected-mode yes port 6379 timeout 0 tcp-keepalive 300 # 访问认证 requirepass prod_redis_password # 内存保护 maxmemory 4gb maxmemory-policy allkeys-lru maxmemory-samples 10 # 持久化方案RDB AOF 混合 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb appendonly yes appendfilename appendonly.aof appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-use-rdb-preamble yes # 慢日志 slowlog-log-slower-than 10000 slowlog-max-len 128 # 复制缓冲 repl-backlog-size 64mb client-output-buffer-limit normal 0 0 0 client-output-buffer-limit replica 512mb 128mb 60 client-output-buffer-limit pubsub 32mb 8mb 60这份模板里需要根据实际环境调整的只有三处requirepass改成你自己的强密码maxmemory按机器内存的 50% 到 60% 设置dir记得指定一个磁盘空间充足且稳定的数据目录。其余参数在大多数场景下都能直接套用。有一点要特别说明maxmemory-policy选 allkeys-lru 的前提是这个实例纯粹做缓存key 丢了还能从业务侧恢复。如果 Redis 里存了不允许丢失的强一致数据比如分布式锁、队列任务状态、业务流水那必须改用volatile-*策略并给这类 key 设置 TTL让逐出器不会碰它们。配置的调整永远跟着业务形态走。我的经验是每次调整配置后都记录一笔变更说明写上为什么调、期望解决什么问题、有没有副作用。这样等下次出问题排查时翻配置变更记录比愣看 redis.conf 里的参数有效率得多。