企业官网建设流程全解析

我刚接手一个项目时，遇到过一次线上Redis连接数被打满的问题。从监控上看，连接数一路飙升直到maxclients上限，紧接着一堆业务告警涌入。第一反应是有人写了个连接泄漏的代码，结果查了半天，最后发现问题出在配置文件上——新加的Redis实例是从一台旧机器直接拷贝过来的，timeout 0表示空闲连接永不断开，连接池里一堆半开连接就堆在那里。那次之后我意识到，Redis的日常运维问题里，十有八九最后都能在配置文件里找到根因。

这篇文章就围绕redis.conf展开：启动时Redis到底怎么加载配置，哪些参数在真实场景中会直接决定线上行为，安全、内存、持久化、主从复制这些模块里哪些配置项最容易踩坑，以及我目前比较顺手的一组基础模板。适合刚接触Redis的后端同学，也适合那些明明能跑起来却总出莫名其妙问题的运维同学。

1. redis.conf 的加载机制：改完文件为什么没生效

先说最基础但也最容易被忽略的一件事：Redis的配置文件到底在什么时机、以什么方式被读取。

1.1 启动时配置加载的优先级

启动Redis时，redis-server可以带一个配置文件路径，也可以不带。不带配置文件时，Redis会使用编译期内置的默认参数启动，并不会自动去某个固定路径找redis.conf。我第一次用源码编译安装Redis时也犯过这个错——以为把redis.conf放在和redis-server同一个目录里就能被自动读取，结果启动后CONFIG GET save一看，和默认值完全一样，配置文件压根没被加载。

正确的启动方式是这样：

redis-server /etc/redis/redis.conf

如果你用apt install redis-server安装，配置文件默认放在/etc/redis/redis.conf，并且init脚本里已经帮你指定了路径。用Docker跑的话，一般通过挂载方式把配置带进去：

docker run -d --name redis \ -v /myredis/redis.conf:/etc/redis/redis.conf \ redis:7.0 redis-server /etc/redis/redis.conf

优先级层面，还有一层隐藏的覆盖关系：命令行参数 > 配置文件 > 内置默认值。也就是说，就算配置文件里写死了端口6379，你启动时加了--port 6380，Redis会以6380为准。这个特性在临时验证配置、或者在配置里没有显式写某个参数时非常有用。

1.2 运行期修改配置：CONFIG SET 与 CONFIG REWRITE

Redis支持动态修改配置，不需要重启：

127.0.0.1:6379> CONFIG SET maxmemory 1gb

这里有个经典陷阱：CONFIG SET只修改内存中的运行时配置，不会自动写回redis.conf。如果你觉得改完了就万事大吉，下次重启，所有运行期修改全部还原。早年间我就在生产环境用CONFIG SET maxmemory-policy allkeys-lru调过淘汰策略，当时确实生效了，结果一个月后机房断电重启，Redis内存涨到物理上限导致OOM，才想起当时的修改根本没落盘。

解决方案是改完后执行一次：

127.0.0.1:6379> CONFIG REWRITE

CONFIG REWRITE会把当前运行配置中与redis.conf不一致的部分，重写回配置文件里。它能保留原来的注释和结构，只更新实际变更的项，对习惯手动管理配置的人来说比较友好。

1.3 配置文件的语法约定

redis.conf的语法很直白，一行一条配置，格式是：

参数名 参数值

例如：

maxmemory 256mb maxmemory-policy allkeys-lru

• #开头是注释。
• 空白行会被忽略。
• 参数名大小写其实不敏感，但业界惯例统一小写。
• 参数值里如果包含空格，需要用双引号包起来，比如requirepass的密码里若带特殊字符。
• 布尔值用yes/no，不要用true/false。
• 字节类的值可以带单位：1kb、256mb、1gb，大小写不敏感。

还有一个常用指令是include，可以在一个配置文件里引入其他文件，常用于按环境拆分配置：

include /etc/redis/redis-local.conf

include出现的位置是有讲究的：Redis是按文件顺序逐行解析，include放在文件前面，后面的配置会覆盖被引入文件里的同名参数；放在文件末尾，则被引入文件末尾的参数会覆盖前面的。这个细节在拆分"公共配置+环境差异化配置"时很容易搞混。

2. bind、protected-mode 与 requirepass：网络与安全配置的三个关键，缺一个都会出事

Redis默认配置是"安全的"，但是安全的方式有点绕。很多刚接触Redis的人配置完成后发现本机能连、远程连不上，或者反过来，配完之后公网裸奔被扫描爆破，根子都在下面这三个参数上。

2.1 bind 到底该怎么填

bind指定Redis监听哪些网卡地址，默认配置通常是：

bind 127.0.0.1 -::1

意思是只监听本机回环地址，只允许本机连接。如果你想允许局域网内其他机器访问，需要把内网IP加进去：

bind 127.0.0.1 192.168.1.100

注意一个容易犯的错：只写了内网IP、没带127.0.0.1，结果本机用redis-cli连接时连不上，因为本机发起连接的目标地址是127.0.0.1，而Redis只监听在192.168.1.100上。通常建议把回环地址保留上。

bind 0.0.0.0表示监听所有网卡。生产环境除非有明确的网络隔离策略，否则不建议这么干。公网上大量针对Redis的扫描爆破，扫的就是裸奔的6379端口。

2.2 protected-mode 的防呆逻辑

Redis 3.2之后引入了protected-mode，它的工作逻辑比较特别：

• 如果protected-mode yes且没有显式配置bind，并且没有设置requirepass密码，那么Redis只接受本机连接。
• 一旦你显式设置了bind（比如绑定到内网IP），但没有设置密码，且protected-mode yes，Redis会拒绝来自非本机的连接。
• 如果显式设置了requirepass，那么受保护模式对密码覆盖的访问就放行了。

这个机制很多老运维会理解为"我bind了内网IP，protected-mode就自动关闭了"，实际情况是——protected-mode仍然是yes，只是这时候从非本机来源进来的连接如果没有密码，直接报DENIED Redis is running in protected mode错误。这个报错我在排查跨机器连接问题时见过很多次。

想彻底放行内网访问又不设密码，得显式设置：

protected-mode no

但这句话等于在裸奔。我的建议是：如果不设密码，protected-mode永远保持默认yes，绑定的IP慎重控制；如果要对外开放，就老老实实打开requirepass，同时配合protected-mode yes使用。

2.3 requirepass 与 masterauth：主从复制绕不开的密码设置

设置访问密码的配置项是：

requirepass your-strong-password

设置后，所有客户端连接都必须执行AUTH your-strong-password。这个密码同样会影响主从复制：如果主库设置了requirepass，从库连接主库时也需要认证，此时从库要配置：

masterauth your-strong-password

masterauth和requirepass是两个独立配置项。requirepass是本实例对外提供服务的认证密码，masterauth是本实例作为从库时连接上游主库的密码。很多新手只设置了主库的requirepass，忘了给从库配masterauth，结果主从一开始复制正常，一旦主从连接断开之后重新建立连接，从库会一直报MASTER auth failed，数据停止同步。这种问题在重启主库后尤其常见，因为断开重连的动作会频繁触发。

如果主从多次切换，比如哨兵模式下主库变成了原来的从库，密码配置就会变得更加微妙。保险的做法是：集群里所有Redis实例的requirepass和masterauth设置为同一个值，这样无论谁变成主库，复制链路都能正常认证。

2.4 ACL：requirepass 的进阶替代

Redis 6.0之后支持ACL，可以针对不同用户设置不同的命令权限和键空间权限。比如只允许某个用户执行只读命令：

user readonly on >readonly-password ~* +@readonly

如果只是想快速搭建、控制复杂度，requirepass仍然是够用的。ACL更适合多团队共享一个Redis实例、需要做权限隔离的场景，但配置文件管理成本更高，一旦配错排查起来也更费劲。

3. maxmemory 与 maxmemory-policy：内存参数配置不当，Redis 可能会被系统杀掉

Redis的内存管理配置，是所有配置项里最容易"凭感觉"乱填的领域。之前遇到过一个实例，maxmemory设成物理内存的100%，想着"反正机器有32G，Redis最多也就全占了"，结果内存到20多G时系统开始使用swap，Redis响应从微秒级飙到秒级，最后进程被内核OOM Killer直接带走。

3.1 maxmemory：设置成多少才合适

maxmemory默认是0，表示不限制内存使用。问题在于，不限制不代表不会出问题——Redis内存膨胀到物理内存上限之后，会动用swap，性能断崖式下跌，最终被系统OOM Kill。Redis自己的报错是"OOM command not allowed when used memory > 'maxmemory'"，但系统层面的OOM Kill往往比这个来得更早、更难排查。

配置建议：如果这台机器上只有Redis一个主要进程，maxmemory设置为物理内存的60%-70%左右，给系统和其他进程留出余量。比如16G内存的机器，设置：

maxmemory 10gb

如果机器上还跑着其他Java应用，要根据实际内存占用情况调低。这里没有绝对公式，原则是：给内核和操作系统留够至少20%的缓冲，避免Redis自身满了之后引发swap风暴。

3.2 maxmemory-policy：淘汰策略怎么选

内存达到maxmemory上限后，Redis根据maxmemory-policy决定行为。默认策略是noeviction，即不再接受写入请求，直接报错，但不影响读操作。对于数据库以外的纯缓存场景，这个默认值几乎是必然会出问题的——缓存写不进去时业务会大量报错。

常用策略对比，直接看这张表：

多数通用缓存场景，我直接用：

maxmemory-policy allkeys-lru

因为大多数业务场景下，缓存数据允许被淘汰，而且LRU策略对"近期访问过、未来可能还会访问"的预测在多数读多写少的场景下表现不错。

但有一个反直觉的场景需要留意：如果你用Redis存了分布式锁，比如一个锁的key设置了过期时间，但业务锁生命周期较长，恰好触发了volatile-lru淘汰，锁会提前消失。使用allkeys-lru时，同样的锁key也可能因为内存压力被淘汰掉。所以在分布式锁场景，内存配置要留足余量，让淘汰概率尽量低。

3.3 maxmemory-samples：采样数对淘汰精度的影响

Redis的LRU和LFU不是精确算法，而是"近似采样"，默认从所有键里随机取5个，淘汰其中最久未使用的一个。这个采样值就是：

maxmemory-samples 5

增大采样数会让淘汰结果更接近精确LRU，但换来的是每次淘汰时更多的内存扫描开销。对于大部分业务，5已经够用。如果Redis里键数量巨大且淘汰频繁，可以提高到10试试，CPU开销会略有提升，一般不影响业务。

4. RDB 与 AOF 持久化配置：数据安全与性能之间的取舍

持久化配置决定了Redis宕机后能找回多少数据。很多从缓存角度理解Redis的人，会直接关掉持久化；很多从数据库角度理解Redis的人，又会开启全部持久化选项。这两种都过于极端，需要按业务接受的数据丢失量来做取舍。

4.1 RDB 快照：save 规则怎么读懂

RDB是Redis在指定时间点生成的全量快照。默认配置长这样：

save 900 1 save 300 10 save 60 10000

规则是"在900秒内至少有1个键发生变化，则执行一次快照"；"在300秒内至少有10个键变化，则执行一次快照"；"在60秒内至少有10000个键变化，则执行一次快照"。满足任意一条即触发。

如果你想完全关闭RDB，注释掉所有save规则，或者显式写一句：

save ""

这里有一个影响很大的配置：stop-writes-on-bgsave-error，默认是yes。意思是如果后台生成RDB快照失败（典型的比如磁盘满了），Redis会拒绝写入请求，直接在业务侧引发大面积写入失败。

这个设计的初衷是为了避免"数据已经无法持久化，但还在持续接新写入"的雪球效应。但对于缓存场景，这个行为反而被认为是"晴天打伞"——反正数据丢了也能重建，不如继续提供缓存服务。所以如果明确是缓存实例、且不依赖持久化，可以改成：

stop-writes-on-bgsave-error no

改这个配置前要想清楚：你确实接受RDB可能写失败、数据丢失，但服务不能停。我一般只在"纯缓存+可重建"的场景才改。

4.2 AOF 日志：appendfsync 的三个档位

AOF以追加日志的方式记录每次写命令，粒度比RDB更细。开启方式：

appendonly yes appendfilename "appendonly.aof"

关键的频率参数是appendfsync，有三个档位：

• always：每次写命令都同步刷盘，最多丢一条命令，但性能开销最大。
• everysec：每秒刷一次盘，最多丢1秒的数据，性能和安全的平衡点，生产环境默认推荐。
• no：由操作系统决定何时刷盘，性能好但数据丢失时间不可控。

我几乎不会把appendfsync设成always，因为写性能损耗很大，对绝大多数业务来说用不上"每次写都保证不丢"。everysec基本是通用选择。

AOF还有一个容易被忽略的项：

auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

AOF文件会不断增长，Redis会在AOF文件体积比上次重写时增长了100%并且超过64MB时，自动触发重写，压缩AOF文件。对于长期运行且写入量大的实例，这两个参数一般不用动，但如果磁盘空间很紧张，可以考虑把auto-aof-rewrite-min-size调大到256mb，降低重写频率。

4.3 RDB 与 AOF 同时开启时的行为

如果同时开启RDB和AOF，Redis重启时优先加载AOF文件，因为AOF包含的命令日志通常比RDB快照更新、更完整。

Redis 4.0之后提供了混合持久化：

aof-use-rdb-preamble yes

开启后，AOF文件头部先写一段RDB格式的全量快照，再追加后续的增量命令。好处是重启加载时先快速载入RDB数据，再执行增量命令，加载速度和数据完整性都兼顾。Redis 7.0中这个配置默认开启，一般不需要手动干预。

4.4 具体业务场景下的持久化选择

我通常按三种场景给配置建议：

• 纯缓存，数据允许丢失：关闭持久化，save ""+appendonly no，最大化性能。
• 需要一定可靠性，但可以接受秒级丢失：开启AOF，appendonly yes+appendfsync everysec，可以不开启RDB。
• 既要有恢复速度，又要尽量少丢数据：同时开启RDB和AOF，aof-use-rdb-preamble yes。

有一种常见误解是"AOF开了一定比RDB慢很多"，实际上在everysec档位下，写性能损耗通常控制在可接受范围，代价主要是磁盘空间占用和文件加载时间。

5. 主从复制与哨兵模式：配置文件里最容易写错的一组关系

Redis主从复制和哨兵高可用，配置本身不算复杂，真正坑人的是多个节点之间参数不联动，尤其是密码、持久化策略和超时时间这类配置在主从间不一致时，平时看不出来，故障时才会爆发。

5.1 从库配置：replicaof 与 replica-read-only

从库的复制配置非常简洁，在主从架构下，从库的redis.conf里加一行：

replicaof 192.168.1.10 6379

这里写主库的IP和端口。复制关系建立后，默认从库是只读的，配置项是：

replica-read-only yes

如果你因为某些特殊需要让从库可写，设置成no。但强烈不建议在生产环境这么做，否则主从数据很快不一致，一旦发生主从切换，这台"脏数据从库"会变成新的主库，整个集群数据就歪了。

还有一个参数在与主库断连时体现：

replica-serve-stale-data yes

默认yes，意思是主从断连后，从库继续对外提供旧数据。这个行为适合"读多写少、短暂断连不影响"的场景。如果业务要求强一致，可以设成no，从库在主从断连期间会拒绝所有请求，提示SYNC with master in progress，但代价是下游读请求全部报错。

5.2 主从增量复制的关键参数：repl-backlog-size

主从复制断线后，如果重连较快，Redis会尝试增量同步——主库把断线期间的写命令从复制积压缓冲区发给从库。这个缓冲区大小就是：

repl-backlog-size 1mb

默认1MB很小。当从库断线时间较长、积累的写命令超过缓冲区大小时，增量同步无法完成，主库不得不做一次全量RDB同步，把RDB文件整体传给从库。全量同步对主库磁盘IO、网络带宽、从库加载时间都有明显影响，大实例甚至会阻塞主库。

建议根据写入吞吐量调整：

repl-backlog-size 64mb

具体值可以估算：假设高峰期每秒写5MB命令，期望容忍从库断线60秒，缓冲区至少需要300MB。很多团队的实例在从库短暂抖动后就触发全量同步，根因就是repl-backlog-size太小。实际配置时我会按预估峰值写入量的2-3倍设置，给突发流量留余量。

5.3 sentinel.conf：哨兵也是配置文件驱动的

哨兵节点不是通过redis.conf管理，而是单独一份sentinel.conf。核心配置：

sentinel monitor mymaster 192.168.1.10 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000

mymaster是给这个主节点取的名字，哨兵配置文件里可以同时监控多个主节点，每个用不同的名字区分。最后的数字2是quorum，表示至少需要多少个哨兵节点同意主库客观下线，才会触发故障转移。

如果主库启用了requirepass，哨兵连接主库也需要认证：

sentinel auth-pass mymaster your-strong-password

如果从库也设置了密码，哨兵在故障转移时会把新的主库地址连同密码一起通知给从库，这个场景下requirepass和masterauth不一致时，故障转移后新主库和从库之间的复制可能直接失败。所以再次强调：主从架构里所有实例的认证信息尽量保持一致。

5.4 一个真实的主从配置故障

有一次处理过一个问题：主库因为磁盘故障重启了，重启后从库日志里一直刷MASTER abored replication with an error: NOAUTH Authentication required。查了一圈，主库的requirepass是最近一次安全加固时新加上的，从库的masterauth没有同步更新。从库一直尝试向主库发起复制请求，但因为没有匹配的认证信息被拒绝。整个过程中主库已经恢复正常，从库却迟迟没有重新同步。修复方式很简单，在从库执行：

127.0.0.1:6379> CONFIG SET masterauth your-strong-password 127.0.0.1:6379> CONFIG REWRITE # 或者直接修改 redis.conf 里的 masterauth 后重启从库

然后重新执行：

127.0.0.1:6379> REPLICAOF 192.168.1.10 6379

复制链路才恢复。这个问题根因不在Redis，而是配置变更管理没有覆盖到所有节点。

6. 我踩过的配置坑，以及现在推荐的基础配置模板

最后分享几个真实的踩坑记录，以及一套我目前在不同场景下都比较顺手的基础配置模板。这些坑的共同特点是：排查时容易往代码层去猜，实际上最后都回到配置文件。

6.1 三个真实踩坑记录

第一个坑：timeout与连接池空闲连接冲突。有台Redis实例配置了timeout 30，本意是回收空闲连接，结果客户端连接池里长期持有的空闲连接被服务端主动关闭，客户端下一次复用连接时才发现连接已失效，直接抛Connection reset。排查了半天，最后在配置里注释掉这行才算完。如果你的客户端连接池本身有心跳检测，服务端timeout设一个较大的值（比如300秒）或者直接保持0更稳妥。

第二个坑：maxmemory设置超过物理内存后触发系统级OOM。实例是16G内存的物理机，配置文件里maxmemory 32gb，本意是"给Redis多留点空间"，结果Redis内存涨到23G时机器开始大量使用swap，Redis命令平均耗时从0.1ms变成800ms，最后整个进程被OOM Killer杀掉。这里的问题在于maxmemory只是Redis层面的内存限制，操作系统层面还有物理内存压力。合理的上限应该远低于物理内存，不能只看Redis自身。

第三个坑：运行期修改配置后没有执行CONFIG REWRITE。有一次临时调大maxmemory-policy解决了缓存淘汰引发的告警，当时确实生效了，后来机房断电重启，Redis加载回原来的配置，告警再次出现，而且这次因为数据量已经涨上来了，直接触发了内存溢出。从此我养成习惯：任何通过CONFIG SET修改的配置，确认无误后立刻执行CONFIG REWRITE落盘。

6.2 我目前推荐的基础配置模板

下面这份模板适用于多数常规业务场景，兼容单机、主从、哨兵模式，读者可以根据实际情况删减调整：

# 基础运行 port 6379 protected-mode yes tcp-backlog 511 timeout 0 tcp-keepalive 300 supervised no daemonize yes pidfile /var/run/redis_6379.pid loglevel notice logfile "/var/log/redis/redis-server.log" databases 16 # 网络与安全 bind 127.0.0.1 192.168.1.100 requirepass your-strong-password masterauth your-strong-password # 内存管理 maxmemory 10gb maxmemory-policy allkeys-lru maxmemory-samples 5 # 持久化（可按业务场景裁剪） save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /var/lib/redis appendonly yes appendfilename "appendonly.aof" appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-use-rdb-preamble yes # 复制相关（从库使用） # replicaof 192.168.1.10 6379 replica-read-only yes replica-serve-stale-data yes repl-backlog-size 64mb replica-priority 100

我的使用习惯是：**先理解每个配置对应的行为边界，再动手调参。**像timeout、maxmemory、appendfsync这种牵一发动全身的参数，改动前会先想清楚这个Redis实例在架构里的角色——是缓存、是数据存储、还是分布式锁的载体，不同角色对同一个参数的合理取值可能是相反的。

配置文件的维护还有一个不容忽视的点：**每次变更都应该像改代码一样走评审和记录，尤其是密码类配置和持久化策略。**Redis的配置项不像代码那样有编译期校验，很多参数写错并不会让你无法启动，而是让实例在运行了几天、甚至几个月之后才以某种隐蔽的方式出问题。把配置纳入版本管理，变更前做好备份，排查问题时能少走很多弯路。