动态网站有个绕不开的瓶颈：每个请求都要查数据库。访问量小的时候没什么感觉，一旦流量上来，数据库的 CPU 和磁盘 IO 会率先扛不住，网站表现为页面打开越来越慢、偶尔 502。Redis 是目前最流行的内存缓存方案，把热点数据放进内存，数据库压力能下降一个数量级。这篇文章从安装、安全配置、缓存策略到三大经典故障，完整走一遍 Redis 缓存搭建的实战流程。
一、Redis 是什么
Redis 是一个基于内存的键值数据库，采用单线程事件循环模型，读写延迟可以做到微秒级。除了基础的字符串，它还支持哈希、列表、集合、有序集合等丰富的数据结构，因此应用场景很广：缓存、会话存储、计数器、排行榜、分布式锁等。对个人网站来说，最常用的两个场景是对象缓存（缓存数据库查询结果）和页面缓存（缓存渲染好的页面片段）。
Redis 之所以快，是因为数据全在内存里，同时单线程模型避免了锁竞争。也正因为数据在内存，它需要额外的持久化机制来防止重启丢数据，这一点后面会讲到。
二、安装 Redis
Debian/Ubuntu 系统一条命令即可安装：
apt update apt install -y redis-server
CentOS/RHEL 系列用 yum install redis。安装完成后启动并设置开机自启：
systemctl enable --now redis-server redis-cli ping
如果输出 PONG，说明 Redis 已经在运行。想体验最新版本，也可以从官网下载源码编译安装，需要 gcc 和 make，过程不复杂，但对个人站长来说，发行版自带的版本通常已经足够稳定，不必折腾。
三、基础配置
Redis 的主配置文件是 /etc/redis/redis.conf，几个关键项逐一说明：
- bind：默认是 127.0.0.1 ::1，只监听本机回环地址，这是最安全的默认值，千万不要改成 0.0.0.0；
- protected-mode：默认 yes，与 bind 配合防止未授权访问，保持开启；
- requirepass：设置访问密码，用强随机字符串，长度至少 16 位；
- maxmemory：根据机器内存设置上限，例如 maxmemory 256mb，给系统和其他进程留足余量，防止 Redis 吃光内存触发 OOM；
- maxmemory-policy：内存达到上限后的淘汰策略，缓存场景推荐 allkeys-lru，只淘汰最久没用的键。
持久化是另一个重点。Redis 提供两种方式：RDB 是定时生成全量快照（默认配置 save 900 1 等），文件小、恢复快，但两次快照之间的数据可能丢失；AOF 是把每次写操作追加到日志文件（appendonly yes，appendfsync everysec），数据更安全，但文件大、恢复慢。缓存场景下数据可以从数据库重建，通常开 RDB 就够；如果缓存里存了不能丢的数据，再考虑 AOF。修改配置后执行 systemctl restart redis-server 生效。
四、安全加固
Redis 历史上出过多次大规模入侵事件，罪魁祸首几乎都是未授权访问：默认配置下 Redis 不需要密码，一旦绑定了公网地址，攻击者就能连上来写计划任务、植入挖矿程序。加固要点如下：
- 绝不对公网开放：用 ss -lntp 查看监听地址，必须是 127.0.0.1 或内网地址；
- 修改默认端口：把 port 6379 改成高位端口，减少扫描器命中概率；
- 设置强密码：requirepass 用长随机串，客户端连接时通过 AUTH 认证；
- 禁用危险命令：通过 rename-command 把 FLUSHALL、CONFIG、EVAL 等重命名或置空，防止攻击者拿到权限后破坏数据；
- 防火墙配合：即使只监听内网，也建议在防火墙层面再限制一层。
这些措施看着多，其实都是配置文件里的几行内容，但对安全性的提升是决定性的。
五、缓存策略：Cache-Aside 模式
个人网站最常用的是 Cache-Aside（旁路缓存）模式，逻辑很清晰：读请求先查 Redis，命中直接返回；没命中则查数据库，把结果写回 Redis 并设置过期时间（TTL）。写请求先更新数据库，再删除对应缓存，而不是更新缓存——因为并发写时更新缓存容易把旧数据写回去，而删缓存让下次读请求重新回填，天然避免脏数据。
TTL 怎么设？热点数据建议 5 到 30 分钟，具体看数据变化频率：几乎不变的数据可以设 1 小时甚至更长，实时性要求高的数据设几十秒。下面是一个 PHP 集成示例（需要安装 phpredis 扩展）：
<?php
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->auth('你的密码');
$key = 'post:' . $postId;
$data = $redis->get($key);
if ($data === false) {
// 缓存未命中，查数据库并回填
$data = $db->query("SELECT * FROM posts WHERE id = " . intval($postId));
$redis->setex($key, 600, serialize($data));
} else {
$data = unserialize($data);
}
?>用 WordPress 的话更简单，安装 Redis Object Cache 插件并启用 phpredis 扩展即可，主题、插件、数据库查询结果都会自动进入缓存。如果用的是 Typecho，也有对应的 Redis 缓存插件，原理相同。另外提醒一点：在 PHP-FPM 环境下，建议使用 phpredis 的 pconnect 长连接，避免每个请求都重新建立 TCP 连接带来的额外开销，对高并发场景的改善很明显。
六、三大经典问题：穿透、击穿、雪崩
缓存用不好，反而会引入新问题，最经典的就是下面三个：
缓存穿透：查询一个根本不存在的数据（比如被恶意构造的 ID），缓存永远不命中，每次请求都打到数据库。解决方案有三：一是参数校验，把明显不合法的请求挡在入口；二是把空结果也缓存起来，设置较短的 TTL（比如 60 秒）；三是在前面加布隆过滤器，用很小的内存成本挡住绝大部分不存在的 key。
缓存击穿：某个热点 key 在过期的一瞬间，大量并发请求同时打到数据库。解决方案是互斥锁：回填数据时先用 SETNX 抢锁，抢到锁的请求查库回填，其他请求短暂等待后直接读缓存。另一种思路是逻辑过期：缓存永不过期，但存一个过期时间戳，读取时发现过期就异步重建，适用于读多写少的场景。
缓存雪崩：大量 key 在同一时间集体过期，数据库瞬间压力爆表。解决方案最实用的是给 TTL 加随机值，比如统一过期时间 600 秒，实际设置成 600 加上 0 到 300 的随机数，让过期时间分散开。此外，热点数据可以配合本地缓存做两级缓存，进一步降低对数据库的冲击。
七、监控与备份
Redis 的监控很简单，一条命令看全局：
redis-cli INFO
重点看几个指标：used_memory（内存使用量）、connected_clients（连接数）、keyspace_hits 和 keyspace_misses（缓存命中与未命中次数），命中率长期偏低说明缓存策略需要调整。实时观察可以用 redis-cli --stat，每秒钟刷新一次。内存增长异常时，用 redis-cli --bigkeys 找出大 key，通常是某个哈希或列表无限制增长导致的。如果命中率持续低于 50%，说明大部分请求还是打到了数据库，这时要检查缓存 key 的设计——常见病根是 key 里带了时间戳或随机参数，导致每次请求生成的 key 都不一样，缓存形同虚设。
备份方面，执行 BGSAVE 生成 dump.rdb 快照，定期把快照拷贝到异地即可；也可以直接 redis-cli --rdb 在线导出。结合定时任务每天备份一次，Redis 挂了也能快速恢复。
八、常见问题
Redis 挂了网站会怎样？取决于代码怎么写。规范的缓存代码在 Redis 不可用时应该自动降级为直接查数据库（fail-open），网站只是变慢，不会打不开；如果代码把 Redis 异常当成致命错误抛出，网站就会直接 500。所以缓存查询一定要包一层异常处理，保证缓存故障不影响主流程。
内存不够用怎么办？一是设置合理的 maxmemory 和 allkeys-lru 淘汰策略，让 Redis 自动淘汰最久没用的冷数据；二是只缓存真正的热点数据，不要什么数据都往里面塞；三是实在不够再考虑升级机器内存。对个人网站来说，128MB 到 512MB 的缓存配额通常已经非常充裕。
什么场景不适合用 Redis 缓存？数据实时性要求极高、每次读取都必须是最新值的场景（比如实时库存、在线状态），以及访问量极小、数据库本身毫无压力的网站——这时候强行加缓存只是增加系统复杂度和排障成本，收益可以忽略。
九、总结
给网站加一层 Redis 缓存，是投入产出比极高的性能优化手段，但前提是配置要安全、策略要正确。记住几条要点：只监听本机、设置强密码、禁用危险命令；用 Cache-Aside 模式并合理设置 TTL；提前想好穿透、击穿、雪崩的应对方案。做到这些，你的网站就能从容应对数倍的流量增长。