Redis实战避坑指南：持久化、缓存三兄弟、大Key与高可用架构全解析

很多人刚上手 Redis 的时候，觉得它就是个大 HashMap，存点缓存、顶个会话，完事了。等真到了线上，流量一冲，各种幺蛾子全冒出来了：一会儿延迟飙到几十毫秒，一会儿数据莫名其妙丢了，一会儿主从切换完应用直接报错。这种时候回头再看 Redis，你会发现自己对它的理解其实停留在“会用”层面，离“用好”还很远。

这篇是第四章的下篇，专门捡实战里最扎手的部分讲。覆盖持久化机制怎么选、缓存穿透/击穿/雪崩怎么防、大 Key 和热 Key 怎么处理、慢查询怎么排查，以及主从、哨兵、Cluster 架构怎么落地。内容偏重经验，每一条都是我在线上环境里实打实踩过的坑，希望能帮你少走点弯路。

1. 持久化：别等数据没了才想到 RDB 和 AOF

1.1 RDB 和 AOF 的核心区别

Redis 的数据默认放在内存里，如果进程一退，内存清空，数据就全没了。要扛住这种情况，Redis 提供了两种持久化手段：RDB（快照）和 AOF（追加日志）。

RDB 就是往磁盘上写一份二进制快照文件。它走的是 fork 子进程的方式，主进程继续服务，子进程把内存里的数据全量落盘。恢复的时候直接把这个快照 load 回内存，速度非常快，尤其适合大实例，几 GB 数据几十秒内基本就能拉起来。但 RDB 有个软肋：它是按触发条件做快照的，默认配置是 900 秒内有 1 次写入、或 300 秒内有 10 次写入、或 60 秒内有 10000 次写入，才会触发一次 save。也就是说，在两次快照之间如果进程突然挂掉，这中间改动的数据会全部丢失。

AOF 走的是另一个思路。每次写命令执行完，Redis 都会把这条命令追加到 AOF 文件末尾，等于是把操作日志原样记录下来。恢复的时候从头到尾把命令重放一遍，就能把数据复原。它的优点是数据安全性高，你可以把 fsync 策略调成每秒刷盘（appendfsync everysec），最多丢 1 秒的数据；缺点也很明显，文件会越来越大，恢复速度比 RDB 慢，AOF 重放几百万条命令也是要花不少时间的。

我之前遇到过一个小伙子，把 AOF 关了只留 RDB，理由是“我们数据没那么重要，丢了也就丢了”。结果某个深夜实例被 OOM Killer 干掉，重启后发现用户当天下午之后的所有操作全没了。那个项目是做线上活动的，当天下午正好是活动高峰期。你说这数据重要不重要？所以选持久化方案这件事，千万别拍脑袋，得按业务等级来算。

1.2 混合持久化：兼顾性能和数据安全

只开 RDB，丢数据；只开 AOF，恢复慢且文件越来越大。那有没有两者兼顾的方案？有，Redis 4.0 开始支持混合持久化，需要在 redis.conf 里把aof-use-rdb-preamble打开。

混合持久化的思路很巧妙：AOF 文件的前半部分是 RDB 格式的二进制快照，后半部分是 Redis 重启之后新产生的增量写命令。这样既利用了 RDB 快速加载的优势，又通过增量命令补足了快照间隔期间的数据。恢复的时候，Redis 先加载前半部分 RDB，再从后半部分重放命令，整体速度比纯 AOF 快不少，数据安全性也比纯 RDB 高。

我个人的习惯是：

• 数据量小、允许分钟级丢失：只开 RDB，省心省力。
• 数据重要、变化频繁：RDB + AOF 同时开，AOF 刷盘策略用everysec。
• 追求极致安全：AOFappendfsync always，每条命令都刷盘，但性能会明显下降，只适合写量很低的场景。

这里补充一个排查经验：生产环境开了 AOF 以后，有时候会遇到 Redis 启动很慢的情况。别慌，先看日志是不是在做 AOF 重写或者 AOF 加载。AOF 文件特别大的话，加载阶段单线程重放命令确实会非常慢。可以用INFO persistence看看aof_rewrite_in_progress和loading相关的字段，确认是不是正在做这些动作。

1.3 持久化踩坑记录

RDB 的触发机制是 fork 子进程。如果你 Redis 实例的内存特别大，比如 20 GB，fork 一瞬间要复制父进程的页表，这个过程是阻塞主线程的。页表越大，阻塞时间越长，甚至可能出现秒级延迟。很多人遇到过“Redis 每隔一段时间就卡一下”的问题，很可能就是bgsave触发了 fork。

查这个问题的办法是看INFO stats里的latest_fork_usec字段，单位是微秒。如果这个值经常飙到几万甚至几十万，说明 fork 开销很大。对应措施是：调大 RDB 触发阈值，降低 fork 频率；或者把内存大的实例拆小，上集群。另外 Linux 内核参数vm.overcommit_memory建议设为 1，这样 fork 时申请内存是“假装成功”，能避免因为内存不足导致 fork 失败。这个参数很多运维会漏配，但影响很大。

AOF 这边也有个坑：AOF 文件达到一定大小后会自动重写，如果你用的是默认配置并且写入量很大，重写可能频繁发生，IO 压力会猛然升高。建议根据写入量，把auto-aof-rewrite-percentage从默认的 100 调整到 200 甚至 300，再配合auto-aof-rewrite-min-size把重写阈值调高，让重写稀疏一些。

2. 缓存穿透、击穿与雪崩：三个必须背下来的“缓存三兄弟”

2.1 穿透、击穿、雪崩到底是什么

这是 Redis 面试必考、线上必踩的三个问题。先理清楚概念。

缓存穿透：请求的数据在缓存和数据库里都不存在。比如一个恶意请求，用一串不存在的 ID 反复打你的接口，Redis 查不到，那就得落库查，落库也查不到，于是这次请求直接穿过缓存打到了数据库上。流量一大，数据库直接被你“问死”。

缓存击穿：某个热点 Key 突然过期，瞬间有大量请求同时发现缓存里没数据，于是全部打到数据库上。和穿透的区别在于，击穿是“某个 Key 过期”，数据库里有数据，只是缓存失效了。击穿是“某个 Key 过期”，数据库里有数据；穿透是“缓存和库里都没这个数据”。

缓存雪崩：大量 Key 同时过期，或者 Redis 整个实例宕机，导致大量请求直接打到数据库。雪崩的范围更广，可以是大规模的 Key 集体过期，也可以是 Redis 节点出问题。

三个问题的本质都是“缓存失效时，请求全部落到数据库”，但诱因、现象、解法都不太一样。

2.2 各场景的应对方案

缓存穿透的常见解法有三种：

第一种是缓存空值。查不到数据时，在 Redis 里存一个空对象，过期时间设短一点，比如 60 秒。这样下一次同样的请求来了，直接命中空值，不落库。这个方案实现简单，但空值会占用一点存储，且有被“用大量不存在 ID 把 Redis 堆满”的风险。所以空值过期时间必须短，还要做好 ID 合法性的前置校验。

第二种是布隆过滤器。在缓存前面加一层布隆过滤器，把所有合法 ID 提前放进去。请求进来先过布隆过滤器，如果 ID 不在里面，直接返回，连 Redis 都不用查。布隆过滤器有一定的误判率，要结合业务容忍度来设置位数组大小和哈希函数个数。误判的结果只是“偶尔放一个不存在的请求过去”，不会造成漏判，所以业务上是安全的。

第三种是接口层限流。从入口做防护，比如根据用户维度限制单位时间内的查询次数，把恶意请求挡在系统最外层。一般生产环境是三种手段组合使用，单纯靠一种往往不够。

缓存击穿的经典解法是互斥锁。当某个热点 Key 过期后，只允许一个线程去查数据库并回写缓存，其他线程在等待期间可以先返回旧值或者短暂阻塞。实现方式可以用 Redis 的SET key value NX EX 5命令做分布式锁，拿到锁的线程去查库回写，没拿到锁的线程 sleep 一会儿再查缓存。

还有一个方案是逻辑过期，不给 Key 设物理过期时间，而是把过期时间放进 value 里。每次读取时发现逻辑过期了，就异步去刷新缓存。这个方案对性能友好，不会出现瞬间阻塞，但实现复杂度高一些，还要防止并发刷新把数据库打崩。

缓存雪崩的应对分两部分。对于“大量 Key 同时过期”，解决思路是给过期时间加随机值，比如SET key value EX 300 + random(0, 60)，让过期时间分散开。还有就是把热点数据设置为永久 Key，配合后台任务定期刷新，相当于把过期动作提前做了。

对于“Redis 实例宕机导致的雪崩”，核心是做好高可用。主从架构加哨兵是底线，关键业务可以上 Redis Cluster。另外强烈建议在应用侧做多级缓存，比如本地进程内再放一层 Caffeine 之类的本地缓存。Redis 挂了以后，本地缓存还能再顶几分钟，给系统争取恢复时间。这个操作在支付、订单这类高价值场景里几乎是标配。

2.3 三个问题放在一张表里对比

很多人在处理这三个问题时只盯着 Redis，忽略了数据库侧的保护。其实数据库连接池上的等待队列长度限制很关键，建议给数据库连接池设置一个最大等待时间，比如 200ms，超时直接快速失败返回，别让请求无限堆积。这是雪崩时的最后一道闸门。

2.4 一个真实场景：活动页缓存雪崩

我之前做过一个运营活动系统，活动库存和商品信息都放在 Redis 里，过期时间统一是活动开始后半小时。结果活动开始后 45 分钟，Redis 里的 Key 全部在同一秒过期，一瞬间数据库的 QPS 从几百飙到几万，数据库连接池被打满，整个应用开始连环超时。

事后复盘，根因就是当时的开发同学图省事，过期时间直接写死为一个常量。修复方案很简单：过期时间设置成3600 + new Random().nextInt(300)，让 Key 的过期时间分散在 5 分钟区间内。另外一个改动是增加了一层本地缓存，虽然容量不大，但能把极端情况下的流量先挡掉一部分。这个案例之后，“过期时间必须随机化”成了我们团队的硬性代码规范。

3. 大 Key 与热 Key：线上事故的头号嫌疑人

3.1 大 Key 的危害不是占用内存那么简单

大 Key 通常指某个 Key 的 value 特别大，比如一个 Hash 里有几百万个字段，一个 List 里有上千万条数据，或者单个 value 的大小超过了几 MB。很多人以为大 Key 只是“占点内存，无所谓”，其实它的危害远超想象。

第一，造成 Redis 阻塞。删除一个几百万字段的 Hash，或者对一个超大 List 做DEL，这条命令会阻塞主线程，阻塞时间可能长达几秒甚至几十秒。这期间 Redis 对所有请求都无响应。这种情况最容易发生在 Key 过期自动删除时，或者运维手动删除大 Key 时。

第二，引发内存碎片和淘汰异常。大 Key 占用的内存是连续的，Redis 内存分配器在分配大块内存时容易出现碎片，导致内存明明没用完，却报 OOM。另外在allkeys-lru淘汰策略下，如果淘汰了一个大 Key，内存会瞬间释放一大块，可能引发主线程阻塞。

第三，影响主从同步。大 Key 在传输到从库时，网络开销大，而且会拖慢主从复制的进度，严重时导致从库复制延迟，主从数据不一致，甚至从库和主库断连后需要全量重同步。

3.2 大 Key 的定位与处理手段

定位大 Key 很简单，用redis-cli --bigkeys就能扫描出实例里占用内存最大的 Key 类型和排名。不过这个命令走的是 scan 采样，不是全量统计，对于哈希、集合这类容器类型，它只统计容器里元素个数最多的前几个，可能不会特别精确。更准确的方式是DEBUG OBJECT命令看序列化长度，或者自己写脚本遍历。

处理大 Key 有几种方式：

• 删除大 Key：用UNLINK替代DEL。UNLINK是异步删除，主线程先把 key 从字典中摘掉，然后在后台线程释放内存，避免了“假死”。生产环境删除大 Key 一律用UNLINK。
• 拆分大 Key：把一个巨型 Hash 拆成多个小 Hash。比如按用户 ID 分段，Hash 字段太多就拆成多个小 Hash，每个 Hash 存固定数量的字段，字段名带上分片序号，查询时先根据规则定位到对应的小 Hash。
• 压缩 value：对于大字符串类型的 value，先用 Snappy 或者 LZ4 压缩再存，用的时候解压。CPU 会有点开销，但内存会省很多。
• 设置合理过期时间：让大 Key 尽量避免“永不过期”，如果数据确实需要长期保留，也要考虑拆分。

我之前排查过一个故障：某接口耗时偶尔会飚到 5 秒以上，追了半天，最后发现是一个 List 类型的 Key 里有 800 万条数据，某次定时任务对这个 List 执行LRANGE全量扫描，一次性读出来传输序列化，把响应时间拖垮了。改成每次只取前 200 条、分批消费之后，接口稳定在 30ms 以内。

3.3 热 Key 引发的问题与应对思路

热 Key 是指某个 Key 被超高频率访问，比如一个热点新闻的 ID，瞬间可能被上百万用户同时查询。热 Key 的危害和普通的高访问不一样：流量集中在某一个 Redis 节点上，一旦这个节点的 CPU 或带宽被打满，整个分片上的其他数据也会跟着变慢。

应对热 Key 最常用的手段是本地缓存。在应用进程里用 Caffeine 或者简单的 Map 做一层短时间缓存，TTL 设置为 2~5 秒。这样热 Key 的流量大部分被挡在应用内存里，Redis 只承受少量回源。这个方案对数据一致性要求不苛刻的场景非常香。

还可以用读写分离。Redis 主库处理写，多个从库处理读，把读流量分散到不同节点上。但热 Key 的本质是一个 Key 的访问量太高，单一从库也可能扛不住，所以更适合的场景是把整体的读压力分散掉。

还有一种是Key 分片。把同一个热 Key 复制成多个带编号的副本，比如hot:news:1、hot:news:2，读请求按照一定规则均匀访问这些副本。写入的时候需要同时写所有副本，读的时候随机选一个。这个方案能在不引入本地缓存的前提下，把热 Key 的流量分散到多个节点上，代价是实现复杂度高。

3.4 日常巡检大 Key 的两个小技巧

我习惯每周用脚本跑一次大 Key 扫描，在凌晨业务低峰期执行，把结果落表，对照上周的数据变化趋势。比如某个 Key 的 value 大小在一周内长得特别快，那就要提前做拆分了，别等它变成“炸弹”。

另一个技巧是监控慢查询日志。SLOWLOG GET 50能拉出最近 50 条慢命令，如果频繁出现DEL、LRANGE、HGETALL、SMEMBERS这类对容器全量操作的命令，基本可以断定存在大 Key 问题，顺着命令里的 Key 去查就行。

4. 阻塞排查：Redis 卡顿的常见元凶

4.1 命令阻塞、fork 阻塞和网络阻塞

很多人在服务端看到 Redis 超时，第一反应就是切集群、上多副本，其实大部分情况用不着这么兴师动众。先用INFO commandstats看看平均耗时和调用次数最高的命令，再用SLOWLOG GET 20拉慢查询日志。这两条命令能帮你快速定位到底是谁在拖慢 Redis。

Redis 是单线程模型，任何一条命令只要执行时间超过预期，就会堵住后面所有命令。最容易引发阻塞的命令集中在几类：KEYS、HGETALL、SMEMBERS、LRANGE全量操作、大 value 的GET/SET。其中KEYS命令最坑，在几百万 Key 的实例上执行一次，Redis 基本就瘫了。生产环境一律用SCAN替代KEYS，这是底线。

fork 阻塞是另一种常见问题。RDB 持久化和 AOF 重写都会触发 fork，如果在 fork 期间内存页表特别大，主线程会被阻塞。这个问题可以通过INFO stats的latest_fork_usec来判断，如果 fork 耗时超过 500ms 就要注意了。

还有一类隐蔽的阻塞叫网络阻塞。当大量客户端同时连进来，或者某个客户端把输出缓冲区拉满，Redis 会因为无法及时发送数据而阻塞。排查方法是看INFO clients，关注client_recent_max_input_buffer和client_recent_max_output_buffer，这两个值如果异常高，就去查是哪些连接导致的。

4.2 慢查询阈值怎么设置

Redis 默认的慢查询阈值是 10000 微秒（10ms），这个值在生产环境太高了。一条命令执行 10ms 才被记录，意味着 Redis 主线程已经被堵了 10ms，这个延迟对线上服务来说已经是灾难级别的体验。

建议把慢查询阈值调低到 1000 微秒（1ms），配置项是slowlog-log-slower-than。这样只要命令执行超过 1ms，就会被记录到慢查询日志里，方便你提前发现潜在风险。

慢查询日志默认只保存最近 128 条，用SLOWLOG RESET清空之后重新积累。排查时可以先SLOWLOG LEN看日志长度，再用SLOWLOG GET N按条数取详情。有个小技巧：如果慢查询日志里经常出现同样的命令和同样的 Key，那就不是偶然问题了，得从代码里根治。

4.3 Redis 变慢的排查套路

我一般按下面这个顺序排查 Redis 变慢的问题：

1. 先看机器负载：top看 CPU、内存、IO。如果 CPU 打满，再看是不是bgsave或者aof rewrite在跑。
2. 再看网络：redis-cli --latency测延迟，排除网络抖动。
3. 看慢查询日志：SLOWLOG GET 50，找出耗时长的命令。
4. 看INFO commandstats的耗时分布，找到平均耗时最高的命令类型。
5. 看INFO persistence里的 fork 耗时和 AOF 重写状态。
6. 最后看是否有大 Key：用redis-cli --bigkeys扫一遍。

之前遇到过一个客户端的 Redis 延迟从 2ms 涨到 50ms，排查到最后发现是bgsave和aof rewrite同时触发了，磁盘 IO 瞬间被打满。优化方式是调整触发阈值，让两者错开，延迟立刻恢复正常。

4.4 别忘了客户端侧的因素

有时候 Redis 本身并不慢，慢的是客户端。最常见的问题有两个：

连接池不够。如果连接池的最大连接数设置得太小，高峰期所有连接都被占满，新请求就得排队等待获取连接，这部分等待时间会算在接口耗时里。建议连接池的大小参考单实例的 QPS 和接口平均执行时间来算：连接数 = 期望QPS × 平均耗时。比如期望 5000 QPS、平均耗时 5ms，那连接数至少需要 25 个。实际中再加一倍冗余，设到 50 比较稳。

命令体过大。如果一次请求要写 1MB 的 value，在千兆网卡下光传输就要 10ms 左右，这还没算序列化和内存拷贝的时间。遇到这种情况要么压缩，要么拆分，否则 Redis 性能再好也架不住数据量太大。

5. 数据结构选型：String 不香吗？什么时候换别的

5.1 为什么别把所有数据都塞进 String

我用过很多团队的 Redis，发现一个很普遍的习惯：什么数据都往 String 里塞。用户信息用 String 存 JSON，订单列表用 String 存数组，一个 String 动不动几十 KB。短时间看不出问题，但到了数据量大的时候，内存开销就上来了。

String 的结构在内存里是有额外开销的，Redis 用了 SDS（简单动态字符串）来存储，每个字符串除了数据本身还要记录长度、空闲空间等元信息。当 value 很小时，这个额外开销占比很高。举个例子，存一个只有 10 字节的字符串，实际占用内存可能接近 100 字节左右，因为还有robj结构体、SDS 头、内存分配器的对齐填充等。

如果你存的是一个几十个字段的用户对象，用 Hash 结构是更经济的选择。Hash 内部有两种编码：ziplist和hashtable。当元素较少、长度较短时，Redis 会自动用ziplist，连续内存分配，省空间，而且批量操作HMGET一条命令就能取多个字段。改成 Hash 之后你可能发现内存占用直接下降一半还多。

5.2 业务场景和数据结构匹配度分析

我一般按下面这个表来选型：

这里说两个容易忽略的点。

一个是 ZSet 适合做排行榜，但要注意 value 的更新频率。如果分数经常变更，ZSet 的写操作是 O(log N) 的，当集合很大时（比如百万级），写性能会下降。这种场景可以考虑先攒一批更新放到内存里，再异步批量写入 ZSet。

另一个是 Set 做交集运算要小心规模。SINTER在集合很大时是时间和内存双消耗，两个 100 万成员的 Set 做交集，可能会卡顿。如果业务上有大量大集合的交集需求，尽量在业务侧控制集合大小，或者用 Lua 脚本来分批处理，避免一次性在 Redis 里算完。

5.3 几个实用命令细节

EXPIRE设置过期时间时，要注意它返回的是设置是否成功，不代表 Key 确实已存在。如果对一个不存在的 Key 设置过期时间，返回是 0。所以在写缓存时，建议用SET key value EX 300这种原子操作，一步到位，避免“设了过期时间但 Key 没写成功”的尴尬。

INCR和DECR是对 String 的原子自增操作，常用于限流和计数器。但要注意，自增后的值如果超过Long.MAX_VALUE（9223372036854775807），会报错。设计计数器时要预估好上限，或者定期重置。

HGETALL在大 Hash 上要慎用，一次性取所有字段和值可能会阻塞 Redis。建议用HSCAN分批取。同理，SMEMBERS在大 Set 上也要用SSCAN替代。若只是获取个数，用HLEN和SCARD就够了，别把全量数据拉出来。

6. 高可用架构：主从、哨兵、Cluster 怎么选

6.1 主从复制与哨兵机制

主从复制是 Redis 高可用的基础。一个主库挂多个从库，从库实时同步主库的写操作。业务读多写少时，可以把读流量分流到从库，减轻主库压力。但主从复制有一个关键问题要记牢：主库挂了，从库不会自动顶上，需要人为干预。这时候哨兵就派上用场了。

哨兵（Sentinel）的作用是监控主库状态。当主库失联超过一定时间，哨兵会发起故障切换，选一个从库提升为新的主库，并通知所有客户端更新连接地址。哨兵本身要部署成奇数个节点，避免投票时出现平局。一般至少部署 3 个哨兵节点，分布在不同的机器上。

用哨兵架构时，客户端的配置要指向哨兵地址，而不是直接指向 Redis 主库。这样主库发生切换后，客户端能自动发现新的主库，不需要手动改配置。这一步很多人会忽略，导致 Redis 切换了，应用还在连旧地址。

6.2 Redis Cluster 的槽位分配与访问规则

单实例内存有限，数据量超过几十 GB 后，单机部署容易出现瓶颈，这时候就要上 Redis Cluster。Cluster 采用无中心化架构，每个节点保存一部分数据，整个集群有 16384 个哈希槽，通过CRC16(key) % 16384计算一个 Key 属于哪个槽，再根据槽的分配规则路由到对应节点。

使用 Cluster 有几点容易踩坑：

第一，不支持多 Key 操作，除非这些 Key 都在同一个槽里。比如MGET、MSET、SINTER这类命令，如果 Key 分布在不同的节点上，会直接报CROSSSLOT错误。解决办法是用 Hash Tag，让相关 Key 的哈希槽相同。比如{user:123}:name和{user:123}:age都只对user:123这段做 CRC16 计算，保证落在同一个节点。

第二，连接方式不一样。客户端连 Cluster 时，连接到任意一个节点后，会收到MOVED重定向响应，客户端再重新连接正确的节点。所以 Cluster 客户端必须支持集群协议，用普通的 Redis 客户端连接 Cluster 是走不通的。

第三，批量操作要分批。需要遍历所有节点分别执行，不能认为一条命令能横扫全集群。比如要统计整个集群的 Key 数量，得在每个节点上分别执行DBSIZE，再汇总。

6.3 架构选择的决策树

我遇到很多团队在上 Redis 架构时，都会纠结主从还是 Cluster。我的建议是画一个决策树：

• 数据量 < 10 GB，读多写少，单机性能还够：主从 + 哨兵即可。
• 数据量 10~50 GB，单机内存吃紧，但能接受业务拆分：考虑按业务域拆成多个 Redis 实例，每个实例独立主从。
• 数据量 > 50 GB，或者单个业务的数据量已经很大，且无法拆分：上 Cluster。
• 对可用性要求极高的核心链路：不管数据量大小，至少要上主从 + 哨兵，Cluster 是加分项。

这里有一个很容易被忽视的问题：Cluster 不是“一键高性能”的银弹。它解决了容量问题，但引入的集群节点越多，运维复杂度越高，还会放大多 Key 操作的限制。如果一个业务的数据量不大，硬上 Cluster 反而会给自己找麻烦。

6.4 故障切换的时间和场景

哨兵或 Cluster 的故障切换不是瞬间完成的。哨兵检测到主库失联，需要经过down-after-milliseconds来判断主观下线，再经过投票确认客观下线，最后选举从库并通知客户端，整个过程通常需要 10~30 秒。这么长的时间窗口内，Redis 是处于不可写状态的。

所以如果你的业务极端依赖 Redis 的写入，且不能接受 30 秒的不可用，就需要在应用层做降级或者本地缓冲。比如把写操作先放在本地队列里，Redis 恢复后再补发。不过这种做法复杂度和风险都很高，一般只有在交易、支付这类核心场景才值得做。

我见过一个做直播弹幕的项目，Redis 挂了以后，客户端发弹幕直接失败。后来改成先把弹幕写到消息队列里，再由消费者写入 Redis，等于在 Redis 前面加了一道缓冲，效果好了很多。这个方案的核心思想是：把 Redis 从“必须可用”降级为“尽量可用”，系统就不那么依赖 Redis 的瞬时可用性了。

7. 监控和运维：Redis 不是装完就能躺平

7.1 需要重点盯的指标

Redis 装好以后，很多人就只管用了，直到线上出问题才去看一眼。其实有几个关键指标应该常态化监控，数据都可以通过INFO命令拿到。

connected_clients表示当前连接数，如果这个值持续上涨且很大，可能说明应用连接池泄漏，或者有客户端没正确释放连接。used_memory是内存使用量，建议设置告警阈值在实例最大内存的 80% 左右。mem_fragmentation_ratio是内存碎片率，正常情况下在 1~1.5 之间，如果超过 1.5 说明碎片较多，考虑重启或者整理。keyspace_hits和keyspace_misses用来计算命中率，命中率在 95% 以下就要检查缓存策略是否合理了。

还有一个容易被忽略的指标是expired_keys，单位时间内过期 Key 的数量。如果这个值突然飙升，大概率是同一批 Key 设置了相同的过期时间，谨防缓存雪崩。

7.2 定期做节点巡检

我习惯每周做一次 Redis 巡检，内容包括：

• 慢查询日志回顾，看有没有新增的慢命令。
• 大 Key 扫描，对比上周大小变化。
• 内存碎片率变化趋势。
• 过期 Key 分布情况。
• 主从复制延迟，用INFO replication看master_repl_offset和slave_repl_offset的差值。

巡检不一定需要多复杂的平台，用脚本把INFO数据抓下来，落表比对上周期数据就够了。重点是持续记录、持续对比，才能发现那些“缓慢变坏”的趋势。

7.3 一个完整的 Redis 告警清单

这些指标看着多，其实一个监控系统（自研脚本或者开源监控组件）就能覆盖。有一说一，监控是前期投入最高、后期回报最大的工程。你永远不知道 Redis 什么时候会出状况，但监控能让你在用户发现之前先发现。

7.4 运维操作的一些安全底线

最后分享几条运维操作的安全准则：

• 删除大 Key 用UNLINK，别用DEL。
• 生产环境禁止KEYS、FLUSHALL、FLUSHDB这类高危险命令，通过rename-command配置把它们禁用或者改名。
• 上线前做压测，确认实例在目标 QPS 下的 CPU 使用率不超过 70%。低于这个水位，突发流量还能抗一抗。
• 变更配置前先备份redis.conf，每次改动留痕。Redis 很多问题都是改配置改出来的。
• 给 Redis 设置内存上限maxmemory，并配好淘汰策略maxmemory-policy。不要在内存满了之后才想起来要配置，那时候 Redis 会拒绝写入，影响面极大。

8. 常用命令速查与避坑清单

8.1 这些命令在实战中值得多用

8.2 三个最常见的“我以为”误区

误区一：Redis 是纯单线程的，性能只能靠单核。实际上 Redis 6.0 之后引入了多线程 IO，虽然命令执行仍是单线程，但网络读写可以并行。如果客户端连接数很大，可以开启io-threads提升吞吐量。不过对大多数应用而言，单线程命令执行依然是主要瓶颈，调整 IO 线程收益有限。

误区二：Redis 挂了重启就行了，不需要担心。如果没开启持久化，重启之后内存数据全空。你的缓存数据可能还能从数据库恢复，但你放在 Redis 里的分布式锁、商品库存这类状态数据，重启后就全丢了，影响可能超出你的想象。

误区三：加内存就能解决一切问题。内存翻倍能缓一口气，但大 Key 导致的主线程阻塞、fork 延迟、网络传输开销并不会因为内存增大而消失。结构设计不合理，内存翻倍只会让问题在更大规模上重新出现。

8.3 本地调试 Redis 的小技巧

日常开发调试时，我会用一个.conf文件记录常用的自定义配置，配合redis-server /path/to/redis.conf启动，这样每次环境都一样。如果只需要临时起一个实例做实验，用redis-server --port 6379 --save '' --appendonly no也能快速跑起来，不持久化、不留垃圾文件。

测试时经常会用到redis-cli的--pipe参数，批量导入命令比一条条SET快得多。比如要把一批数据导入 Redis，可以先拼出 Redis 协议格式的文本文件，然后执行cat data.txt | redis-cli --pipe，导入速度轻松上十万条每秒。这个技巧在数据迁移、缓存预热时非常有用。

排查连接异常时，redis-cli -h 127.0.0.1 -p 6379 ping是最快的连通性测试。如果 PING 通但业务请求超时，那问题大概率不在 Redis，而是客户端连接池、网络代理或者应用线程池出了问题。

9. 结尾：一次 Redis 故障的复盘复盘再复盘

写这篇文章的时候，我回忆起一次印象很深的故障。某个周五晚高峰，一个核心服务突然大面积超时，用户反馈页面转圈。排查下来，根因是一个被错误设计的数据结构：一个 List Key 被当作消息队列用，消费者处理速度跟不上生产速度，List 快速增长到几百万条，然后一次清理任务对这个 List 执行了DEL，Redis 主线程直接阻塞了 20 多秒。20 多秒的阻塞导致所有依赖 Redis 的接口集体超时，连锁反应拖垮了下游服务。

那次故障给我的教训很大。首先，数据结构选型不能想当然，List 做队列要严格控制长度，消费能力必须兜底。其次，清理大 Key 之前要有意识，先确认体积再操作，操作时用UNLINK。最后，监控和重试机制能救命，但没有提前发现风险的话，监控也只是事后诸葛。

Redis 是个好东西，但它只是在帮你管理数据，真正决定数据安全的还是你自己。架构上留足冗余，代码里选用合理的数据结构，运维上提前发现隐患，这三件事做好了，Redis 的实战路就稳了。希望这篇下篇里的经验和教训，能让你少踩几个我踩过的坑。