企业官网建设流程全解析

记一次Redis生产事故：从凌晨告警到全链路治理

凌晨2点17分，我被值班手机连续震醒。监控平台显示Redis集群的CPU使用率从12%飙到了98%，缓存命中率断崖式下跌，核心订单接口P99延迟从30ms涨到了4.8秒。打开电脑的那一瞬间，我脑子里只有一句话：这回又出大事了。

这次事故持续了将近一个半小时，期间线上出现了局部不可用，部分用户的购物车和登录会话受到影响。事后复盘，根因并不复杂，但暴露出来的问题涵盖了Redis使用规范、监控体系、容量评估、代码质量等多个方面。很多朋友都在用Redis，但只停留在“会用”的层面，遇到突发故障容易手忙脚乱。我把这次完整的排查和治理过程记录下来，针对大key、热key、缓存穿透、内存淘汰、序列化、连接池等问题都做了详细拆解，希望对正在使用或者准备使用Redis的同学有一些实际参考价值。这不是一篇概念科普，而是一份可以照着操作的实战记录。

1. 问题爆发：那些年我们在Redis上埋下的雷

1.1 故障现象：从慢查询到雪崩的完整链条

先说我们当时的部署情况：Redis单节点，版本6.2.5，部署在一台8核16G的云服务器上，最大内存设置了10G，淘汰策略用的默认的noeviction。业务方主要是两个团队共用一个实例，存的内容包括用户登录会话、购物车数据、商品详情缓存、秒杀库存、分布式锁，还有一部分临时性的业务状态位。

事故发生的当天，运营团队刚好上线了一个“整点秒杀+拉新返现”的活动，流量比平时高了近十倍。凌晨时段的流量平日是很低的，但这个活动是全时段开放，结果在凌晨2点迎来了一个爬虫+脚本刷量的小高峰。

故障的表现是逐步恶化的：

• 前20分钟：Redis的CPU使用率从15%慢慢爬到40%，命令响应时间从0.3ms涨到2ms左右，此时业务方没有感知。
• 第25分钟开始：有一个热点商品的库存key被脚本高频访问，每秒请求量从几千涨到十几万。Redis是单线程模型，所有命令在一个线程里排队执行，这个高QPS直接把CPU干到了80%以上，其他所有命令的响应时间开始指数级上升。
• 第40分钟：大量请求超时，缓存穿透开始出现。原本能命中缓存的商品详情和用户信息，因为Redis阻塞没能写入缓存，所有请求直接打到数据库。数据库的连接数和慢查询数量同时飙升，最终形成“Redis阻塞→缓存穿透→数据库压力暴增→数据库处理变慢→更多请求超时→缓存继续无法回填”的恶性循环。

我后来看到监控面板上的曲线图，Redis的CPU、阻塞客户端数、内存碎片率三条曲线几乎是垂直向上的。那种感觉就像看大坝崩溃的监控画面，一切都在几秒钟内失守。

1.2 第一时间的排查动作：分秒必争的保命操作

故障发生后的前几分钟，我做了这么几件事：

第一，立刻用redis-cli连上实例，执行了SLOWLOG GET 50，查看最近50条慢查询。结果非常惊人，有不少执行时间超过3秒的命令，而且全部集中在两个命令上：KEYS和HGETALL。

第二，执行INFO commandstats，按调用次数和执行总耗时排序，找到了热命令的分布。统计结果显示，一个固定前缀的KEYS匹配操作占据了总命令执行时间的60%以上，而一个HGETALL操作频繁操作一个包含几十万字段的大哈希。

第三，执行INFO memory和INFO clients，确认当前内存占用已经达到9.8G，接近上限，连接的客户端数量也超过了预期的最大值。

这些命令的结果一下就把问题范围缩小了：大key和热key是明面上的罪魁祸首，但更深层的问题是代码里用错了Redis命令和数据结构。

这里要特别提醒一点：线上出问题时，别急着重启服务。先抓现场，把慢日志、当前连接数、内存快照、命令统计这些数据都记录下来，再评估是否需要重启。否则重启之后问题看似解决了，但根因还会在下一次流量高峰时卷土重来。

2. 快速止血：先恢复可用，再谈追查根因

2.1 临时策略：限流、剔除大key、扩容内存

面对已经雪崩的线上服务，第一时间不是写代码修复，而是把流量和风险先控制住。

我当时执行的操作是按优先级排序的：

第一步，在Redis前面加一层限流。当时我们用的是自研的网关，直接对那个热点商品接口的请求做了一级限流，把QPS压到原来的十分之一左右。这一步是为了让Redis喘口气，避免请求继续把所有命令队列塞满。

第二步，处理大key。那个几十万字段的哈希表，我先用HKEYS和HLEN确认了大小，然后直接用UNLINK命令把它从内存中删除。UNLINK是异步删除，不会阻塞主线程，这种场景下比DEL安全得多。删除之后，Redis的CPU和内存占用肉眼可见地回落了大概20%。

第三步，临时调整淘汰策略。因为我们用的是noeviction，内存满的时候新写入会直接报错，这在写入高峰期会引发连锁失败。我临时把maxmemory-policy改成了allkeys-lru，允许Redis在内存达到上限时按最近最少使用算法自动淘汰一些不重要的key。这是应急手段，不是长久之计，但确实能让服务先跑起来。

第四步，数据库连接池那边也做了临时兜底。把连接池的最大连接数和超时时间都调小了一些，让数据库能扛住瞬时穿透的请求，不至于被压垮。

这一套操作下来，大概过了十分钟，接口的P99延迟回落到500ms以内。虽然还是比正常水平高，但至少系统从“即将崩溃”的状态里拉了回来。

2.2 为什么“先止血”比“马上改代码”更重要

很多没有真正经历过线上事故的同学，遇到问题第一反应是“我马上改代码”。但在Redis这种基础设施故障面前，直接改代码是最差的选择。

原因是代码改动从提交到发布有一套完整的流程，即使你改了能立刻发，也要考虑改动对现有业务的影响，这个时间成本在分钟级甚至小时级。而Redis本身的问题往往可以通过配置调整、数据结构优化、限流熔断这些手段在几十秒内缓解。

以这次事故为例，真正引发雪崩的是KEYS命令和大key的HGETALL，但如果不先限流，即使你把代码改好了，旧代码还在线上跑，新流量还是会持续打进来。止血是给系统争取时间，改代码才是从根本上解决问题。两者顺序不能反。

我在这次事故里的体会是：止血操作要“快、准、狠”，不要犹豫。该限流就限流，该删key就删key。记住UNLINK替代DEL、CONFIG SET做动态调整、CLIENT KILL清理异常连接，这三个命令在关键时刻都能保命。

3. 根因定位：把慢日志和监控数据翻了个底朝天

3.1 慢查询日志里的真相：KEYS命令与热Key

故障恢复后，我开始静下心来做完整的根因分析。第一步是导出了故障时间段的所有慢日志明细。

慢日志里最大的问题确认无误：是一个定时任务在每次执行时会用KEYS命令模糊匹配一批前缀为user_session:*的key来做数据清理。这个任务每隔5分钟跑一次，正常时候数据量不大，KEYS执行耗时在几十毫秒。但那天凌晨会话数量暴增，user_session:*的key总量达到几百万，KEYS命令被要求遍历全量key空间，单次执行耗时达到了5秒以上。

KEYS命令的危害在于，Redis是单线程模型，一次全量遍历会阻塞其他所有命令。这在低峰期可能感觉不到，但在高峰期就是灾难。

另一个慢日志热点是HGETALL操作。这个哈希key存放的是一个商品的完整详情数据，包括规格、图片URL列表、SKU信息、卖点文案等，字段数量达到了40多万个。每次HGETALL把整个哈希全部序列化传回客户端，网络I/O和序列化开销都极大，单个请求耗时2-3秒。

这类问题在Redis社区里叫“大key”问题。判断大key有三个维度：单个key的value大小超过10MB、集合类型的元素数量超过1万个、以及单个key的读写耗时明显高于平均值。这三个维度占一个就算大key，日常巡检必须覆盖。

3.2 内存淘汰策略的隐患：一场“压缩式”雪崩

除了大key和KEYS，还有一个隐藏的推手是内存淘汰策略。

我们当时使用的是默认的noeviction。这个策略的语义是：当内存使用达到maxmemory时，所有写命令直接返回错误，不支持淘汰任何key。日常使用中这算是一个“保守且安全”的方案，至少不会因为淘汰导致数据丢失。但在写入量大的时候，它会让写命令失败，间接导致缓存无法回填。

那天凌晨Redis内存已经达到9.8G，接近10G的maxmemory上限。当大量的写请求进来后，大量SET和HSET命令开始报OOM错误，缓存写入失败，业务方只能去查数据库，数据库压力随之暴涨。

这里还有一个很多人忽略的细节：即使你把maxmemory-policy改成了allkeys-lru，如果内存接近上限，Redis会不断循环扫描并淘汰key，这个淘汰过程本身也会消耗CPU。如果同时有大量设置了过期时间的key到期，Redis清理过期key的机制也会加剧CPU消耗。所以不要等到内存满了再去调策略，容量规划要留出20%-30%的缓冲空间。

3.3 配置了连接池就不会出连接问题？不存在的

我们使用的是Spring Boot+Lettuce连接客户端，默认的连接池配置比较小。高峰期的连接请求量超过了连接池的最大上限，导致大量线程在等待获取连接。Lettuce本身是异步客户端，但底层通信仍然会受系统socket缓冲区限制。

确认这个问题的方式很简单：在故障时段看Redis的INFO clients，观察connected_clients数量，以及netstat统计4306端口的TCP连接数，两者都远超平时。

连接池问题在这次故障中不是最致命的原因，但它放大了故障面。当Redis变慢之后，连接等待时间变长，连接池的线程被占满，新的请求只能排队，这进一步拉长了整体的响应时间。所以排查Redis故障时，一定要连着检查客户端侧的连接池配置和线程池状态。

4. 解决方案：从配置、代码到架构的系统性治理

4.1 参数级调优：把Redis配置从“默认”改为“生产可用”

第一件事是重新梳理Redis的配置参数。以下是我这次调整后比较有代表性的一套生产方案，可以作为参考：

参数调整不能拍脑袋。每个参数改动前，都要对照当前业务场景想想“为什么”，改完后要观察一段时间，确认没有副作用。比如timeout设成300秒，如果业务里存在长连接场景（比如WebSocket依赖Redis Pub/Sub），就要小心空闲断开导致的消息丢失。这时候更合适的做法是为这类长连接单独建立专用实例。

持久化策略我们也做了重新评估。之前RDB和AOF都开着，AOF的rewrite频率很高，每次rewrite都会fork子进程，内存占用翻倍，对CPU和磁盘I/O都有压力。我们把RDB的save策略调成了“900秒内至少1次变更”，AOF维持everysec，并配置了auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 1G，让AOF重写不要太频繁。

4.2 代码侧修复：大key拆分、SCAN替代KEYS、布隆过滤器防穿透

配置调优只能缓解症状，真正要解决问题，必须把代码里的雷拆掉。

第一个雷：KEYS命令替换为SCAN扫描。

KEYS会阻塞Redis主线程，SCAN是基于游标的增量迭代，可以分批次执行，不会阻塞服务。我把那个定时任务改成了使用SCAN游标循环匹配前缀的方式，把一次全量匹配拆成了多次小批量匹配，每次匹配结束读取下一个游标继续。

SCAN的坑在于，在迭代过程中如果有key被创建或删除，可能出现重复或遗漏。但这个业务场景是清理会话数据，对一致性要求不高，能接受这种概率性的不精确。如果你需要精确匹配，还可以考虑用Redis 6.0以后引入的客户端缓存，或者干脆把这类数据存到专门的索引结构里。

第二个雷：大哈希拆分。

商品详情的那个哈希，我们做了两个方向的优化。首先是过期时间分层：把图片URL列表这类不太变化的数据放到独立的key里，设置较长的过期时间；把库存、价格这类实时性要求高的字段单独存。其次是数据压缩：图片URL列表改成JSON数组字符串并用GZIP压缩之后再存入，读取时解压。这样单个key的value从几十MB降到了几百KB，HGETALL的操作耗时从秒级降到了毫秒级。

这里要特别说明：不是所有大key都必须拆掉。如果大key是业务核心数据结构，拆分会带来很大的代码改动和一致性问题。更合适的做法是“分级”：冷数据异步淘汰，热数据按分片存取。比如用户购物车，可以按userId分组，而不是所有人共用一个哈希。

第三个雷：缓存穿透和缓存击穿。

商品详情缓存有穿透问题：当某个商品ID在数据库中不存在时，缓存里也不会写入，导致每次查询都穿透到数据库。解决方案是布隆过滤器。我引入了一个布隆过滤器来拦截不存在的商品ID，只有当ID“可能存在”时才去查询数据库。布隆过滤器的误判率设置的1%，内存占用可以忽略不计。

此外，对于重建缓存开销很大的热点缓存，我们加了一个分布式锁双检机制：缓存未命中时，先尝试获取分布式锁，拿到锁的线程才去查数据库并回填缓存，其他线程等待一段时间后重新读取缓存。这样避免了“缓存击穿”时大量请求同时涌入数据库。

4.3 序列化问题：JDK序列化的空间浪费

聊到Redis就绕不开序列化这个话题。我们当时使用的Spring Data Redis默认的RedisTemplate用的是JDK序列化，存进去的对象会带上完整的类结构信息，一个简单的对象存成字节数组后体积膨胀了三四倍。这在内存和带宽上都是浪费，间接也加大了大key问题的风险。

排查过程中我实际测试了一下：一个正常的用户对象，JDK序列化后的二进制大小约为425字节，而用JSON序列化后只有180字节左右，相差一倍还多。

我们的解决方案是在配置类里显式声明使用GenericJackson2JsonRedisSerializer替代默认的JdkSerializationRedisSerializer。但注意，换成JSON序列化之后，反序列化回来的对象是LinkedHashMap，需要手动转换为目标类型。如果项目里用了很多RedisTemplate，建议封装一个通用的RedisUtil工具类，统一处理类型转换。

4.4 架构层面：从单节点到主从加哨兵

单节点Redis意味着单点故障。这次的CPU打满虽然没导致宕机，但给了我们一个强烈的信号：必须做高可用改造。

我们采用的方案是主从复制加哨兵模式，架构是一个主节点两个从节点加三个哨兵进程。主节点负责读写，两个从节点负责读流量分担和故障切换。读写分离后，主节点的CPU压力直接下降了40%左右。

部署方式上，我们用Docker Compose管理整个Redis集群。下面是简化版的docker-compose.yml，供参考：

version: '3.8' services: redis-master: image: redis:6.2.5 container_name: redis-master command: ["redis-server", "/usr/local/etc/redis/redis.conf"] volumes: - ./master/redis.conf:/usr/local/etc/redis/redis.conf - ./master/data:/data ports: - "6379:6379" networks: - redis-net redis-slave1: image: redis:6.2.5 container_name: redis-slave1 command: ["redis-server", "/usr/local/etc/redis/redis.conf"] volumes: - ./slave1/redis.conf:/usr/local/etc/redis/redis.conf - ./slave1/data:/data ports: - "6380:6379" networks: - redis-net depends_on: - redis-master redis-slave2: image: redis:6.2.5 container_name: redis-slave2 command: ["redis-server", "/usr/local/etc/redis/redis.conf"] volumes: - ./slave2/redis.conf:/usr/local/etc/redis/redis.conf - ./slave2/data:/data ports: - "6381:6379" networks: - redis-net depends_on: - redis-master sentinel1: image: redis:6.2.5 container_name: sentinel1 command: ["redis-sentinel", "/usr/local/etc/redis/sentinel.conf"] volumes: - ./sentinel1/sentinel.conf:/usr/local/etc/redis/sentinel.conf ports: - "26379:26379" networks: - redis-net depends_on: - redis-master sentinel2: image: redis:6.2.5 container_name: sentinel2 command: ["redis-sentinel", "/usr/local/etc/redis/sentinel.conf"] volumes: - ./sentinel2/sentinel.conf:/usr/local/etc/redis/sentinel.conf ports: - "26380:26379" networks: - redis-net depends_on: - redis-master sentinel3: image: redis:6.2.5 container_name: sentinel3 command: ["redis-sentinel", "/usr/local/etc/redis/sentinel.conf"] volumes: - ./sentinel3/sentinel.conf:/usr/local/etc/redis/sentinel.conf ports: - "26381:26379" networks: - redis-net depends_on: - redis-master networks: redis-net: driver: bridge

从节点的redis.conf需要添加replicaof redis-master 6379，三个从节点分别配置不同的端口映射。哨兵配置文件需要指定监控的主节点信息和quorum值。quorum建议设置为2，表示至少两个哨兵认定主节点故障才触发切换，能有效避免网络抖动引起的误判。

这套方案不一定适合所有业务，如果你的数据量已经达到几十上百G，读写QPS在十万以上，就需要考虑Redis Cluster。我们当前的数据量还在主从加哨兵的承受范围内，所以优先选了更简单的方案。

5. 事后复盘：一套可落地的Redis全链路治理方案

5.1 监控告警体系：从“事后救火”到“事前发现”

这次事故最让我后怕的是事前几乎没有任何预警。监控平台虽然有Redis的基础指标采集，但只关注了内存使用率这一个指标，CPU、慢查询、阻塞客户端数、命中率、连接数这些关键指标统统没有配置告警。

事故之后，我把Redis监控指标做了一轮完整的梳理，需要重点盯的指标包括：

这些告警不是一次性配完就结束了。要定期检查告警是否真的有效，最直接的办法是用人为构造的异常流量做故障演练，看告警能不能在预期时间内触发。

5.2 容量评估与压测：别等打满再扩容

Redis的容量规划要同时考虑内存、CPU、带宽和连接数四个维度。

内存方面：Redis的数据量通常不会无限增长，但要为峰值流量预留空间。我们评估的口径是，当前业务日增数据量的30倍作为安全余量，再叠加maxmemory的20%缓冲。

CPU方面：单线程模型的瓶颈非常明显。如果日常CPU使用率超过50%就要引起重视了，因为Redis的CPU峰值通常出现在流量高峰、淘汰扫描、AOF重写、RDB快照这几个叠加场景下，瞬时能达到平时的数倍。

带宽方面：如果单个key的value过大，或者大key数量过多，网卡会成为最先打满的瓶颈。我们这次事故中KEYS命令返回几百万个key，单次响应就有几十MB，直接吃满了内网带宽。

压测是验证容量规划的唯一手段。我们用redis-benchmark对不同的命令类型和key大小做了流量模拟，对比了调整前后的吞吐量。实测数据：调整前，在10字节的小value条件下，SET命令单实例QPS大概在8万左右；调整后，加上连接池优化和参数调优，QPS稳定在10万以上。这个数据帮助我们建立了容量基线。

5.3 研发规范：从工具到流程的双重约束

监控和容量只解决“发现”和“预防”的问题，真正堵住源头还得靠研发规范。事故发生后，我们整理了三条硬性规范：

第一，禁止在线上使用KEYS命令，统一改用SCAN。这条规范写进了代码评审的检查清单里，同时在代码仓库配置了静态扫描规则，一旦出现KEYS关键字直接阻断合并请求。

第二，对redis客户端操作封装统一入口。我们封装了RedisUtils工具类，所有业务方必须通过工具类访问Redis，不再允许直接注入RedisTemplate。这样做的目的是：可以统一做序列化、连接池配置、慢操作拦截、大key告警切片，未来如果要切换客户端库或者升级版本，也只需要动一个地方。

第三，上线前必须走一次Redis数据结构和容量评审。我们做了一个简单的checklist：数据结构选型是否合理、key的TTL是否有明确设定、是否涉及大key热key操作、单次读写的数据量估算、是否会有KEYS/全量扫描风险。每一项都要有负责人确认签字。

6. 常见问题与排查技巧实录

6.1 典型故障速查表

这次事故处理过程中，我对照了很多网上资料，也踩了几个别人没踩到的坑。整理了一份常见故障的速查表，帮助大家在做排查时快速定位方向：

6.2 排查思路与工具推荐

事故排查有一个原则，我反复跟团队讲：先看全局，再看局部；先抓现场，再找根因。

全局层面的工具有三个必备的：redis-cli的--stat模式可以实时刷新看命令数和内存；INFO命令的各个section按需提取；Redis自带的redis-benchmark做压测基线。

另外，我强烈推荐你在本机装一个Redis Desktop Manager或者Another Redis Desktop Manager。可视化管理工具看key的分布、内存占用、过期时间非常直观，排查慢日志和实时监控也效率高。不过生产环境的敏感操作，比如删除数据、修改配置，我还是坚持在shell里用redis-cli完成。原因很简单：命令行操作有审计日志，每次执行了什么命令都能追溯，GUI工具误操作的概率更高，而且很难留痕。

还有一个小技巧，Redis 6.0以上版本自带了一个叫redis-cli --bigkeys的扫描工具，可以快速扫描当前实例的大key分布。我每隔一段时间就会跑一次这个大key扫描，输出结果里按类型列出了最大的几个key和它们的字节数，这对排查内存上涨和慢查询问题非常有帮助。不过注意，这个命令在高峰期不要跑，它本身会遍历全量key，也会消耗性能。

另外一个排查冷门规律：如果CPU高但慢日志没多少，多半是AOF重写或者RDB save触发了fork。用INFO stats看latest_fork_usec，如果这个值特别大，建议把RDB的save策略调整一下，或者把持久化操作迁移到从节点执行。

6.3 长期运维经验：把“头大”变成“日常”

处理完这一轮事故，我对Redis运维有了更深的体会。这里分享三个长期有效的小经验：

第一个经验是定期的“Redis健康体检”。我每个月会在低峰期执行一次全量巡检，内容包括：大key扫描、内存碎片率检查、慢日志统计、持久化状态确认、连接数变化趋势、命中率变化。全部结果汇总成一张表格，问题项标记成红灯。

第二个经验是善用内存碎片整理。Redis的jemalloc内存分配器在频繁增删数据后，会产生严重的内存碎片。碎片率在1到1.5之间是正常的，超过1.5就要考虑重启，或者使用CONFIG SET activedefrag yes启用自动碎片整理。这个命令在高峰期的CPU损耗比较明显，建议错峰开启。

第三个经验是关于分布式锁的。很多项目用Redis实现分布式锁，但踩过的坑真不少。建议直接使用Redisson客户端，它内置了看门狗机制处理锁过期问题，还支持RedLock。如果自己用SETNX实现锁，一定要记得设置过期时间，并且value要带唯一标识，释放锁时用Lua脚本原子地比较并删除。

写在最后的一点心里话

这次事故处理完，我在团队例会上说了一句话：Redis本身很少出问题，出问题的往往是我们怎么用它。KEYS命令、大key、没有监控、没有容量评估，这一系列问题如果能早点暴露，根本轮不到它在凌晨2点把我们的系统拖到崩溃边缘。

踩过这次坑之后，我们的Redis从单节点升级成了主从加哨兵，所有代码强制走统一的操作入口，监控面板上随时能看到核心指标。但我最大的变化不是技术层面，而是心态层面的——任何看似稳定的系统，都会在你最松懈的时候给你致命一击。基础设施的运维没有“一劳永逸”，只有不断复盘、持续加固，才能在下一个流量高峰到来时，安然无恙地喝下一杯咖啡。