企业官网建设流程全解析

1. 调配置前，这些背景知识得先摆在台面上

很多人搭 Redis 第一步就是下载、解压、启动，然后业务代码一连，能跑通就觉得完事了。直到某一天线上突然连接被拒、内存被打满、重启后缓存数据全没，才开始翻配置文件找原因。Redis 出问题，七成以上都不是代码逻辑的锅，而是配置没吃透。

先说清楚这篇要讲的范围：不聊源码，也不聊复杂的集群编排，就把 redis.conf 里最常用的、生产环境真正用得上的那些参数掰开揉碎讲清楚，按场景给出模板和排错手段。适合刚接手 Redis 的开发者、运维同学，也适合那些“用了很久但没仔细看过配置”的老手拿来查漏补缺。

一个核心事实得先记住：Redis 的配置文件，本质就是一堆指令（directive）加参数的组合。每条指令一行，参数紧跟其后。默认配置往下翻，你会发现注释特别多，很多指令的初始值也特别保守。这个保守不是坏事，恰恰是作者故意设计的：在没搞懂参数含义之前，不要把保护机制轻易去掉。我见过太多人上来就把 bind 改成 0.0.0.0 然后裸奔在公网上，结果被扫描器命中，数据直接被刷掉，场景极其惨烈。

1.1 版本差异带来的配置语义差异

动手改配置前，先确认自己的版本。我用redis-server --version查过太多环境，发现大家手上跑的版本差异巨大：有古老的 2.8，有使用率极高的 5.x，也有现在主流的 7.x。

版本差异直接影响配置写法：

• 2.8 时代slaveof、slave-read-only是标准写法，5.0 之后虽然还兼容这些旧名词，但官方推荐改用replicaof、replica-read-only。如果你在 7.x 的配置里看到一堆slave开头的旧参数，能跑，但语义不清晰，容易被新文档误导。
• 3.2 之后 maxmemory-policy 支持把volatile-lru、allkeys-lru等策略分得更细；4.0 加入LFU（Least Frequently Used）策略；6.0 起引入了 ACL（Access Control List），requirepass不再是唯一的认证手段。
• 4.0 之后持久化支持混合模式（同时用 RDB 和 AOF），这个特性后面我会展开讲。
• 6.0 之后多线程 IO 成为可选特性，相关参数是io-threads，但默认配置里看不到，需要手动添加。这个参数不调没事，调了反而容易踩坑，原因后面讲。

所以如果你的生产环境还在跑 3.x 甚至 2.8，网上一堆 7.x 的配置模板复制下来大概率是跑不动的。我之前接手过一个老项目，运维直接把新版本配置丢给老版本，启动直接报错，日志提示 unrecognized directive，排查了半天才发现是版本不匹配。

1.2 默认配置不等于“不用配”

Redis 的默认配置设计得很巧妙：默认情况下，你直接./redis-server就能跑起来，适合开发调试。但默认配置拿到生产环境，有几个致命短板：

• 默认不限制内存使用（maxmemory 为 0，意思是不限制），意味着 Redis 会一直吃内存直到系统 OOM。这不是耸人听闻，机器内存 16G，Redis 里面塞了 20G 的数据，系统直接 OOM Killer 把 Redis 干掉，业务雪崩。
• 默认不开启 AOF 持久化，只开了 RDB。默认的 RDB 快照规则是“至少 3600 秒内有 1 次写操作”等等，宕机丢数据的窗口非常大。
• 默认没有密码保护，只靠 protected-mode 撑着。这个模式在“没有密码 + 不能绑定非本机地址”的情况下才会真正生效，一旦你为了远程访问把 bind 改成 0.0.0.0 但忘了设密码，等于把大门敞开。
• 默认 daemonize no 是前台启动，终端一关就退出了一个服务，这不是 bug，是刻意为之：配合 systemd 或者 docker 的场景，前台运行才是正确的做法。

所以结论很直接：开发环境可以用默认配置省心，生产环境必须手工梳理一遍关键参数。这也是我写这篇的初衷，把“哪些参数必改、为什么改、改多少合适”一次性讲清楚。

2. 核心参数逐个拆解：你只需要搞懂这九个

redis.conf 里面的参数零零总总上百个，但真正影响稳定性、安全性和性能表现的，仔细想想也就那么几个。下面按照网络上和实际运维里经常打交道的几个维度来拆解。

2.1 网络与安全组：bind、protected-mode、requirepass

bind

这个参数管的不是“允许谁来连接”，而是“Redis 服务监听在哪个网络接口上”。默认值是127.0.0.1 -::1，意思是只监听本机的 IPv4 回环地址和 IPv6 回环地址。这样只有本机上的程序能连，外面任何机器都访问不到，开发自测是够用的。

如果你有几个应用服务器需要连这台 Redis，就需要把 bind 改成本机内网 IP，或者直接0.0.0.0。我的建议是：

• 单机部署、只给本机应用用：保持默认127.0.0.1，不要动。
• 内网多机器互访：bind 改成服务器的内网 IP，而不是 0.0.0.0。这样即使你忘了设密码，外网从物理上也连不进来。
• 只有确实需要从任意地址访问（比如容器环境中的固定映射关系），才考虑 0.0.0.0。一旦这么改，requirepass 和防火墙必须跟上。

protected-mode

这个参数是 Redis 2015 年为了安全加上的“最后一道保险”。它的逻辑比较绕：当且仅当“没有配置密码”且“bind 不是只绑本机”时，会让 Redis 拒绝来自非本机的连接，并在日志里给出提示。

换句话说，protected-mode 本身不阻止任何连接，它只在你在裸奔状态下帮你拦一道。如果你有密码、或者 safe bind，这个参数开不开都无所谓。但我不建议把它设成 no，因为没有任何收益。真要远程访问，老老实实设密码比关保护模式靠谱一百倍。遇到过不少案例：某人为了图省事，protected-mode no 一关，bind 0.0.0.0，密码也不设，扫到之后 get 一下直接写走数据，几分钟时间整个缓存库就没了。

requirepass

这个参数就是设置一个全局密码。客户端连接时执行AUTH 密码，或者连接串里带上密码才能通过。

• 6.0 之前这是唯一的认证手段。
• 6.0 之后引入了 ACL，可以用redis-cli -u redis://user:pass@host:port这种方式对接，或者在配置里逐条设置用户。但 requirepass 依然好用、够用，绝大数中小项目都靠它。

实践中有个细节：主从架构下，从库也要在配置里写 masterauth，否则从库连不上主库做同步。我们后面讲主从配置时会再说。

踩过的坑：requirepass 只对普通命令生效，CONFIG、SHUTDOWN这些管理命令同样需要认证；不过 Redis 内部的一些运维通道（比如复制流的初始建立）不受 requirepass 影响，得额外配 masterauth 覆盖。

2.2 内存与淘汰策略：maxmemory、maxmemory-policy

maxmemory

这个参数不设，Redis 就不知道自己的内存上限在哪。它会把所有能用的内存都攒下来塞数据，直到操作系统开始 swap 或者 OOM。

设置原则要说清楚：Redis 运行本身需要内存，不只是存数据。比如 5.x 之后引入了很多新的数据结构编码，哪怕一个 key 只存 1 个字节，开销也可能在几十上百字节。所以 maxmemory 的设置不是简单地“数据量多大就设多大”，而是要给操作系统预留一点余量。

推荐经验：如果机器专门跑 Redis（或 Redis 主进程主要吃内存），maxmemory 设置为物理内存的 60%~70% 是安全的。比如专门 16G 的机器，设 10G~12G。如果机器上还跑着其他服务，那就要估算出 Redis 和数据总量之后留出 buffer。一个自查脚本的思路是：用INFO memory查看 used_memory_rss，观察它吃满时的比例，反推合理阈值。

maxmemory-policy

当达到 maxmemory 上限后，Redis 要对新写入失败还是挤出旧数据，这个就由淘汰策略决定了。常用以下几种：

我通常的建议是：业务上是纯缓存、丢几万个 key 也无所谓，用allkeys-lru；如果数据需要长期保留、过期期限明确，用volatile-lru；千万别用noeviction又不开持久化，因为内存满之后 Redis 直接变成只读状态，线上立刻报错，回写任务全军覆没。

2.3 持久化组：RDB、AOF、混合模式

Redis 持久化有两个基本选项：RDB 快照和 AOF 日志。

RDB

RDB 是把全量数据在某个时刻拍成二进制快照存盘。默认配置里这样的规则：

save 3600 1 save 300 100 save 60 10000

含义是：3600 秒（1小时）内至少 1 次写命令、300 秒内至少 100 次、60 秒内至少 10000 次，满足任一条件就会触发一次 bgsave。这种设计的初衷是平衡性能和安全性，但对生产来说有个问题：宕机前最后一次快照之后的数据，全丢了。要大幅度缩短丢失窗口，只能加 AOF。

AOF

AOF 记录每次写命令本身，重启时回放命令来重建数据。配置要点：

appendonly yes appendfsync everysec

appendfsync有三个值：

• always：每个命令都刷盘，最安全但性能损失很大。
• everysec：每秒刷一次盘，最多丢 1 秒数据，性能和安全性平衡得好，生产首选。
• no：由操作系统决定刷盘时机，性能最好但丢数据不可控。

实测下来，普通业务用 everysec 足够，RDB 和 AOF 同时开着也没问题。注意 AOF 文件会无限增长，所以还带一个auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，用来触发重写瘦身。

混合模式

4.0 之后 Redis 引入了混合持久化，配置是aof-use-rdb-preamble yes。简单理解：AOF 文件头部先放一个 RDB 快照，后续再追加增量命令。这样重启的时候先加载 RDB，再增量回放，比纯 AOF 回放快很多，文件体积也比纯 AOF 小。7.0 起这个默认就是 yes，老版本建议手动开启。

有个坑必须提醒：如果你用纯 AOF 从 2.x 升级到 4.x，旧文件可能不是 RDB 前缀格式，加载逻辑自己会兼容处理，但中途手动把aof-use-rdb-preamble从 yes 改成 no，会触发一次 AOF 重写，这期间主进程会阻塞，大实例上很容易体验一把“卡顿”。所以这个参数在运行阶段不要随便变。

2.4 连接与慢查询：tcp-backlog、timeout、slowlog

tcp-backlog

这个参数是 TCP 层的连接队列长度。默认是 511，但对高并发应用，连接建立的速度瓶颈往往在操作系统层面的 somaxconn。Linux 上默认 somaxconn 可能只有 128，tcp-backlog 511也发挥不出来。建议在/etc/sysctl.conf里把net.core.somaxconn调大，比如 1024 或 2048，Redis 这边保持默认或者同步加大。

排查时最有意思的现象：高并发下redis-cli能连上，但应用端大量connect timeout，多半就是 backlog 队列被打满，而 tcp-backlog 本身设置不当或者和系统 somaxconn 不匹配。

timeout

timeout 0表示不主动关闭空闲连接。这个参数对连接数敏感的业务影响很大：如果客户端连接池做成长期保持，timeout 设成 300 秒，结果客户端空闲 5 分钟就被服务端断开，客户端感知的就是“断连”，不得不重连，积攒下来 QPS 会很难看。所以我建议这里就保持 0，让客户端连接池自己去管理生命周期。

但 0 也意味着 Redis 不回收空闲连接，连接数过多时内存开销上涨。折中方案是配合tcp-keepalive 300，让系统层面定期探活，把半死连接清掉，而不是依靠超时硬切。

slowlog

slowlog-log-slower-than 10000表示记录执行耗时超过 10000 微秒（10毫秒）的命令。线上我习惯设为 5000（5毫秒），因为 Redis 单线程模型下，命令阻塞几百毫秒就会拖垮整体请求。

查看方式：redis-cli slowlog get 20能看最近 20 条慢日志。配合CONFIG SET slowlog-log-slower-than 5000可以在线调整，但生产环境建议写进配置，不然重启就丢。

3. 三种场景的模板配置，照着改就能用

理论说完了，直接上模板。我给出的三个模板都是从实际部署中整理出来的，不是空谈。

3.1 单机开发环境模板

适合本机联调，要求：启动快、无认证麻烦、可以随时重启不心疼数据。

bind 127.0.0.1 protected-mode yes port 6379 daemonize no databases 16 # 开发环境不设密码，只绑本机 # requirepass yourpassword maxmemory 256mb maxmemory-policy allkeys-lru save "" appendonly no

这里把 save 设为空，表示关闭自动 RDB；appendonly no 表示不开 AOF。开发环境图的是方便，不追求重启后数据恢复。但你如果正在调一个跟缓存丢失相关的 bug，建议临时开着 AOF，方便排查旧数据和现网逻辑。

3.2 生产单机模板

注意区分：生产单机不是“单节点开发”，而是给线上业务做缓存或存储的独立实例。这里强调安全与持久化。

bind 0.0.0.0 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize yes pidfile /var/run/redis_6379.pid logfile /var/log/redis/redis.log loglevel notice databases 16 requirepass 生产环境改成强密码 masterauth 主从时从库需要用到 maxmemory 10gb maxmemory-policy allkeys-lru save 3600 1 appendonly yes appendfsync everysec aof-use-rdb-preamble yes slowlog-log-slower-than 5000 slowlog-max-len 128

如果这台机器内存 16G，maxmemory 10G 是我常用的比例。这个模板在生产部署时可以直接微调使用。特别强调一下：如果从库不需要写操作，配置replica-read-only yes。

3.3 主从复制模板

主从复制分两个角色。主库配置基本和生产单机一样，额外需要开启replica-read-only（默认本来就是 yes）。从库配置则在普通配置基础上加：

replicaof 10.1.2.3 6379 masterauth 主的认证密码 replica-read-only yes replica-priority 100

replica-priority是哨兵选主时的优先级，数字越小越容易被选成主库。如果你某个机房的所有从库都不希望被选为主，直接把这个数设成 0，哨兵就不会选它。

主从建立之后，检查状态用redis-cli info replication，关注master_link_status:up和master_repl_offset。从库同步进度以 offset 为准，主从 offset 差太多，说明复制延迟或者断连了。

这里要额外提一个坑：Redis 主从复制的全量同步全靠 RDB 快照。如果主库数据量大，首次全量同步时主库要 fork 子进程生成 RDB，期间内存占用翻倍，所以主库的 maxmemory 要留出 enough 头部空间，别把内存压到真实物理内存的 95%。

4. 常见问题与排查心得

配置好 Redis 并不难，难的是出问题时能快速判断是哪段配置引起的。下面是我实际排查中总结的几个高频问题，以及对应的定位思路，整理成速查表供大家参考。

4.1 连接被拒与 protected-mode 的纠葛

最常见的远程连接失败，就是 protected-mode 和 bind 的组合在作祟。很多人想从办公电脑连线上 Redis，把 bind 改成 0.0.0.0，但没设密码，这时候 protected-mode 反而会拒绝一切非本机连接，表面现象是连接超时。

解决办法很简单：设 requirepass，或者把 bind 明确绑定到办公网能访问的内网 IP 上。很多人把 protected-mode 关掉来“解决”，这是饮鸩止渴。

4.2 密码不生效

排查思路：

• 配置文件生效了吗？redis-cli连上之后执行CONFIG GET requirepass，如果返回是空，你设的密码根本没加载。这种情况八成是启动时没指定配置文件，或者配置写在别的文件里。
• 密码有特殊字符吗？!、#、$在 shell 里可能被解释，要用引号包住。配置文件里requirepass abc#123中的#如果没加引号，会被当成注释，后半截直接没了。我见过某团队把密码设成带#的字符串，实测 AUTH 一直失败，排查半天发现配置行被截断。
• ACL 和 requirepass 叠加时，ACL 优先。6.0 之后如果配置里有user default on ...这种段，可能 public 用户的密码会覆盖 requirepass 行为，要小心。

4.3 重启丢数据

这个坑在“只依赖 RDB”时尤其明显。设了save 3600 1，意味着如果 1 小时之内只有不到 1 次写操作，Redis 不会自动生成快照，一旦进程被杀，最近数据全没。很多人天真地以为重启不会丢数据，因为在测试环境很难察觉。

我的做法是生产环境必须同时开 AOF，并开启混合持久化。AOF 默认采用 everysec 刷盘，理论上最多丢 1 秒的写。配合 RDB 全量快照，重启恢复速度也可控。

4.4 慢查询与大 key 阻塞

Redis 的慢查询不只是命令执行慢，还可能是“删除大 key 时阻塞主线程”。Redis 删除一个上百万字段的 hash 是同步操作，删除期间整个 Redis 不响应。遇到这种场景，不能用 DEL，要用UNLINK（4.0 之后支持），它是异步删除。

定位大 key 的方法：redis-cli --bigkeys能按类型扫描出最大的 key。还有一个实际经验：把latency-monitor-threshold 100打开，再用redis-cli --latency观察延迟分布，排查阶段很有用。

4.5 数据被突然清空

这种事故我见得多。FLUSHALL / FLUSHDB 误操作，或者因为脚本里有清缓存逻辑，参数传错导致整库清除。预防手段：

• 配置里启用rename-command FLUSHALL ""，把 FLUSHALL 禁掉。如果业务确实需要清库，再单独开放一条命令别名，比如rename-command FLUSHALL "FLUSHALL_BAK"。
• 更彻底的做法是通过 ACL 限制运行命令的权限。正常业务账号只给读写权限，不给 FLUSHALL、KEYS、CONFIG 这类高危命令。
• 开启 AOF 之后，即使误清了，还能通过回放日志抢救一部分，没有 AOF 的话就真的只能从备份恢复了。

另外提一句日常备份：RDB 文件在配置里指定dir /data/redis存好之后，用 crontab 每天把 RDB 拷贝到单独的备份目录，同时配合 AOF 的日志留存。真遇到 FLUSHALL，先停写，拷贝当前 AOF 文件，再从 RDB 恢复到几分钟前，比想象中麻烦得多，别太指望手动抢救。

最后分享一个我个人的习惯：上线前把CONFIG GET *的返回结果留一份存档，每次变更后对比一下。Redis 很多参数用CONFIG SET在线改完之后不会自动落到配置文件，机器一重启又回到老样子。特别是 maxmemory、appendonly、slowlog 这类参数，改完必须手动同步到 redis.conf 里，或者执行CONFIG REWRITE把现网配置写回文件。我吃过几次亏，后来一律以配置文件为唯一事实来源，能不改运行期就不改。这样出了问题，翻文件就是全部答案，不给自己留太多隐性变量。