Redis生产事故复盘：从大key到缓存穿透的全链路治理

记一次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 BootLettuce连接客户端默认的连接池配置比较小。高峰期的连接请求量超过了连接池的最大上限导致大量线程在等待获取连接。Lettuce本身是异步客户端但底层通信仍然会受系统socket缓冲区限制。确认这个问题的方式很简单在故障时段看Redis的INFO clients观察connected_clients数量以及netstat统计4306端口的TCP连接数两者都远超平时。连接池问题在这次故障中不是最致命的原因但它放大了故障面。当Redis变慢之后连接等待时间变长连接池的线程被占满新的请求只能排队这进一步拉长了整体的响应时间。所以排查Redis故障时一定要连着检查客户端侧的连接池配置和线程池状态。4. 解决方案从配置、代码到架构的系统性治理4.1 参数级调优把Redis配置从“默认”改为“生产可用”第一件事是重新梳理Redis的配置参数。以下是我这次调整后比较有代表性的一套生产方案可以作为参考配置项原值调整后调整理由maxmemory10G12G物理内存预留30%给业务增长留缓冲避免频繁触发淘汰maxmemory-policynoevictionallkeys-lru缓存类key允许自动淘汰避免写入OOMtimeout0不超时300关闭空闲连接减少连接资源浪费tcp-keepalive060及时清理已断开的TCP连接maxclients1000015000适配峰值连接数但配合监控使用appendfsynceveryseceverysec保持默认兼顾数据安全与性能slowlog-log-slower-than100001000记录超过1ms的操作便于发现问题slowlog-max-len1281000多存一些慢日志方便回溯参数调整不能拍脑袋。每个参数改动前都要对照当前业务场景想想“为什么”改完后要观察一段时间确认没有副作用。比如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降到了几百KBHGETALL的操作耗时从秒级降到了毫秒级。这里要特别说明不是所有大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监控指标做了一轮完整的梳理需要重点盯的指标包括指标类型具体指标告警阈值建议资源类CPU使用率连续5分钟超过70%资源类内存使用率超过maxmemory的80%资源类内存碎片率大于1.5或小于1命令类慢查询数量每分钟超过5条命令类单条命令耗时P99超过50msclient类已连接客户端数超过最大连接数的80%数据类缓存命中率低于85%数据类过期key数量超过总量的10%数据类大key数量单个key value超过10MB同步类主从复制延迟超过30秒这些告警不是一次性配完就结束了。要定期检查告警是否真的有效最直接的办法是用人为构造的异常流量做故障演练看告警能不能在预期时间内触发。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 典型故障速查表这次事故处理过程中我对照了很多网上资料也踩了几个别人没踩到的坑。整理了一份常见故障的速查表帮助大家在做排查时快速定位方向故障现象可能原因排查命令解决思路CPU飙升热key高并发、KEYS扫描、AOF重写INFO commandstats、SLOWLOG拆热key、SCAN替代KEYS、调AOF rewrite阈值内存满但配置正常内存碎片、大key、淘汰策略不当INFO memory、MEMORY DOCTOR定期清理大key、调maxmemory-policy、重启时重新加载读写延迟突增网络抖动、慢命令阻塞、主从切换redis-cli --latency、SLOWLOG检查网络、优化慢命令、检查哨兵日志缓存命中率低过期时间设置不合理、缓存穿透INFO stats优化TTL、引入布隆过滤器、加分布式锁连接数打满连接池配置过小、连接泄漏INFO clients、netstat调大连接池、修复连接泄漏、设置timeout数据丢失主节点宕机未切换、持久化失败INFO persistence配哨兵/Cluster、定期备份RDB响应数据乱码序列化方案冲突直接GET查看原始字节统一序列化方式、换GenericJackson2JsonRedisSerializer6.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从单节点升级成了主从加哨兵所有代码强制走统一的操作入口监控面板上随时能看到核心指标。但我最大的变化不是技术层面而是心态层面的——任何看似稳定的系统都会在你最松懈的时候给你致命一击。基础设施的运维没有“一劳永逸”只有不断复盘、持续加固才能在下一个流量高峰到来时安然无恙地喝下一杯咖啡。