整点一到,数据库 CPU 瞬间飙满、全站雪崩:我给所有缓存设了同一个过期时间,亲手制造的那场缓存雪崩

这是一次让我刻骨铭心的整点故障。我负责的服务,在数据库前面加了一层 Redis 缓存,扛住了绝大部分的读请求,平时数据库压力很小、岁月静好。可不知从哪天起,服务开始出现一个诡异的规律:每到整点(比如 10:00、11:00 这种),数据库的 CPU 就会在一瞬间,从平时的百分之十几,直接飙到 100%,接口大面积超时,整个站点卡顿甚至雪崩;而过了一两分钟,又自己恢复正常,仿佛什么都没发生。

这种"准点发作、发作完又自愈"的故障,排查起来格外费劲。我盯着监控看了好几个整点,才慢慢琢磨出问题的关键:每次 CPU 飙升的瞬间,数据库的查询量会暴增几十倍——平时被缓存挡掉的请求,在那一瞬间,全都涌向了数据库。这意味着,在那个整点的瞬间,缓存,集体失效了。我顺着这个线索深挖,终于揪出了元凶,也对自己的疏忽懊悔不已:我在预热缓存、把大批数据一次性加载进 Redis 时,给它们设置了完全相同的过期时间(比如统一 1 小时)。于是,这成千上万条缓存,就在加载后的同一时刻、整整齐齐地、同时过期了!它们同时失效的那一瞬间,海量本该被缓存挡住的请求,就同时穿透缓存、同时砸向了数据库——数据库被这突如其来的洪峰瞬间打垮。这,就是高并发架构里赫赫有名的"缓存雪崩(Cache Avalanche)"。

故障现场:成千上万条缓存,同一秒过期

我把出问题的缓存加载逻辑,简化一下。问题就藏在那个"统一的过期时间"上:

import redis
r = redis.Redis()

# 缓存预热: 启动时, 把大批热点数据一次性加载进缓存
def warm_up_cache():
    all_products = db.query("SELECT * FROM product WHERE is_hot = 1")  # 上万条热点商品
    for product in all_products:
        # ✗ 致命: 所有缓存, 设了【完全相同】的过期时间 3600 秒!
        r.set(f"product:{product.id}", product.to_json(), ex=3600)
    # 假设这个预热在 9:00 执行完
    # → 这上万条缓存, 都会在 9:00 + 3600秒 = 10:00 这一刻, 【同时过期】!

# 10:00 整, 这上万条缓存同时失效, 然后:
def get_product(pid):
    data = r.get(f"product:{pid}")
    if data is None:               # 10:00 这一刻, 上万个请求同时发现缓存没了!
        data = db.query(f"SELECT * FROM product WHERE id = {pid}")  # 同时砸向数据库!
        r.set(f"product:{pid}", data, ex=3600)
    return data
# → 10:00 瞬间, 上万个请求同时穿透缓存、同时查数据库 → 数据库 CPU 瞬间打满!

看清这个"统一过期时间"的设计,我才明白那场整点雪崩是怎么来的。我在 9:00 执行缓存预热,把上万条热点数据一次性塞进 Redis,并给它们每一条都设置了相同的 3600 秒(1 小时)过期时间。这意味着,这上万条缓存,会在 9:00 + 1 小时 = 10:00 整,这同一个时刻,整整齐齐地、一条不差地、同时过期失效。而在它们集体失效的那一瞬间,平时被这些缓存稳稳挡住的、成千上万的读请求,会同时发现"缓存里没数据了",于是同时地、一窝蜂地、全都去查数据库——这相当于把平时被缓存"削平"的流量洪峰,在 10:00 那一秒,毫无缓冲地、原封不动地,全部砸向了数据库。数据库,平时只需要应对缓存漏过来的少量请求,根本扛不住这突如其来的、几十倍于平常的查询洪峰,CPU 瞬间被打满、查询排队、大量超时——整个服务,就在这缓存集体失效的一刹那,雪崩了。而过一两分钟,等这些请求陆续把缓存重新填上,流量又被缓存挡住,服务便"自愈"了——直到下一个整点,同样的悲剧再次上演。我亲手用一个"统一的过期时间",给系统埋了一颗每小时定时引爆的炸弹。

第一件事:搞懂缓存雪崩——"同时失效"是关键

定位到根源,我把"缓存雪崩"这个概念,以及它的成因,彻底搞明白了:缓存雪崩,指的是在某一个时刻,大量的缓存同时失效(过期或丢失),导致原本被这些缓存挡住的海量请求,同时穿透到后端数据库,瞬间给数据库带来巨大的、远超其承受能力的压力,从而导致数据库甚至整个系统的崩溃。"雪崩"这个词,形象地描述了这种"瞬间的、压垮性的"流量冲击。

缓存雪崩的核心: 大量缓存"同时"失效, 流量"同时"砸向数据库。

正常情况(缓存有效):
  请求 → 缓存命中 → 返回 (数据库压力很小)
  缓存就像一道"大坝", 把海量请求挡在外面, 只放少量水流到数据库。

雪崩瞬间(缓存同时失效):
  请求 → 缓存全没了 → 全部涌向数据库
  "大坝"突然整个垮了 → 海量请求的洪水, 瞬间全部砸向数据库 → 数据库被冲垮!

雪崩的两种典型成因:
  成因1: 大量 key 设了【相同的过期时间】, 到点同时过期 (我踩的坑!)
  成因2: Redis 服务器宕机, 所有缓存瞬间全没了 (整个缓存层挂掉)

为什么数据库扛不住?
  缓存能扛 10万 QPS, 数据库可能只能扛 5千 QPS。
  平时缓存挡掉 95%, 数据库只需扛 5%。
  雪崩瞬间, 那 95% 的流量全砸过来 → 数据库被 20 倍流量瞬间压垮。

  关键: 缓存的价值, 不只是"快", 更是"保护后端数据库"。
       缓存雪崩, 本质是这个"保护层"在一瞬间, 集体失效了。

原理终于清晰了。缓存雪崩的核心,就两个字——"同时":大量缓存在同一时刻同时失效,导致海量请求同时砸向数据库。平时,缓存就像一道挡在数据库前面的"大坝",把汹涌的请求洪水挡在外面,只让少量水流到数据库,数据库因此岁月静好;可一旦这道"大坝"在某一瞬间整个垮掉(大量缓存同时失效),被挡了一路的洪水,就会在那一刻毫无缓冲地、全部砸向数据库,瞬间把它冲垮。而这背后,是一个容易被忽略的事实:缓存和数据库的承载能力,往往相差悬殊——缓存(Redis)可能轻松扛住每秒十万次查询,而数据库可能只能扛每秒几千次;平时缓存挡掉了 95% 的流量,数据库只需应付剩下的 5%,所以一切正常;可雪崩瞬间,那本该被挡掉的 95% 流量,全都砸了过来,等于让数据库瞬间承受了 20 倍于它能力的压力——它当然会被压垮。这让我深刻地认识到:缓存的价值,绝不只是"让访问变快"这么简单,它更是一个至关重要的、"保护后端数据库不被流量冲垮"的"保护层";而缓存雪崩,本质上,就是这个"保护层",在一瞬间,集体失效、彻底失守了。我那个"统一过期时间"的疏忽,正是亲手制造了这场"保护层集体失守"的灾难。

第二件事:正解——给过期时间"加随机",让缓存错峰失效

搞懂了根因——"大量缓存同时失效"——正解就一目了然:既然问题是"同时",那解法就是"打散"——给每条缓存的过期时间,加上一个随机的偏移量,让它们的失效时间,分散到一个时间段里,而不是挤在同一个时刻。这样,就算缓存批量过期,也是'细水长流'地陆续过期,而非'决堤洪水'般地同时过期。

import random

# 正解1: 给过期时间加随机偏移, 让缓存"错峰"失效
def warm_up_cache_fixed():
    all_products = db.query("SELECT * FROM product WHERE is_hot = 1")
    for product in all_products:
        # ✓ 基础 3600 秒 + 随机 0~600 秒, 让过期时间分散在 1小时 ~ 1小时10分 之间
        ttl = 3600 + random.randint(0, 600)
        r.set(f"product:{product.id}", product.to_json(), ex=ttl)
    # → 上万条缓存的过期时间, 现在均匀分散在 10分钟 的窗口里,
    #   而不是挤在 10:00 那一秒 → 数据库压力被"摊平", 不再雪崩!

# 这个随机偏移有多关键? 算一笔账:
#   原来: 上万条缓存, 在 1 秒内全部过期 → 瞬间上万 QPS 砸向数据库
#   现在: 上万条缓存, 均匀分散在 600 秒内过期 → 平均每秒才几十条过期
#         → 数据库每秒只多承受几十个查询, 轻松扛住!

# 关键认知: 随机偏移的本质, 是把"集中的失效", 变成"分散的失效",
#   从而把"瞬间的洪峰", 变成"平缓的细流"。

这个正解,简单到只加了一行 random.randint(0, 600),却从根本上化解了雪崩。它的核心思想,是用"随机化",把"集中"变成"分散"。原来,上万条缓存因为过期时间完全相同,会在同一秒内全部过期,造成瞬间上万 QPS 的洪峰;而加上一个 0 到 600 秒的随机偏移后,这上万条缓存的过期时间,就被均匀地分散到了一个 10 分钟(600 秒)的时间窗口里——平均下来,每秒钟只有几十条缓存过期、几十个请求穿透到数据库,这点压力,数据库轻轻松松就能扛住。同样是缓存批量过期,"同时过期"是一场雪崩,而"错峰过期"则平淡无奇——区别仅仅在于,你有没有给过期时间,加上那一点点至关重要的"随机"。这就是随机化的威力:它把一个'瞬间的、压垮性的洪峰',化解成了一条'平缓的、可承受的细流'。

下面这张图,对比了"统一过期"和"随机错峰过期"两种方式:

这张图的对比很清楚:左边红色那条,所有缓存设相同 TTL,到点同时失效,海量请求同一秒砸向数据库,造成雪崩;右边绿色那条,给 TTL 加随机偏移,缓存失效时间被分散到一个时间段,每秒只有少量缓存过期,数据库压力被摊平、平稳承受。两条路的根本分野,就在那一个小小的、却价值千金的"随机偏移"。

第三件事:雪崩、击穿、穿透——缓存的"三大经典坑"

填平了雪崩,我把缓存相关的几个"经典坑"系统地梳理了一遍。我发现,缓存雪崩,其实只是缓存"保护层失效"这一大类问题里的一种;它还有两个"亲戚"——缓存击穿和缓存穿透,三者常被一起讨论,但成因和解法各不相同:

# 缓存的"三大经典坑": 雪崩、击穿、穿透 (容易混淆, 必须分清!)

# 1. 缓存雪崩(Avalanche): 【大量】key【同时】失效 → 海量请求砸数据库 (本文的坑)
#    解法: 过期时间加随机; Redis 高可用(防整体宕机); 多级缓存

# 2. 缓存击穿(Breakdown): 【单个热点】key 失效的瞬间, 大量请求同时穿透
#    场景: 一个超热的 key(如爆款商品), 它过期的一刹那,
#          成千上万的请求同时发现它没了, 同时去查数据库、同时重建缓存。
#    解法: 加"互斥锁"——只让第一个请求去查库重建, 其它请求等它建好:
def get_with_mutex(key):
    data = r.get(key)
    if data is None:
        if r.set(f"lock:{key}", 1, nx=True, ex=10):  # 抢到锁的, 才去查库
            data = db.query(...)
            r.set(key, data, ex=3600)
            r.delete(f"lock:{key}")
        else:
            time.sleep(0.05); return get_with_mutex(key)  # 没抢到锁的, 稍等重试
    return data
#    或: 热点 key 干脆"逻辑过期"/不过期, 后台异步更新。

# 3. 缓存穿透(Penetration): 查询【根本不存在】的数据 → 每次都穿透到数据库
#    场景: 恶意/异常请求, 一直查一个数据库里根本没有的 id(如 id=-1),
#          缓存里永远没有(因为查不到), 每次都打到数据库。
#    解法a: 把"空结果"也缓存起来(缓存一个空值, 短过期), 挡住后续相同查询
    if data is None:
        result = db.query(...)
        r.set(key, result or "EMPTY", ex=60)  # 即使查不到, 也缓存个空标记
#    解法b: 用布隆过滤器(Bloom Filter), 快速判断"这个 id 一定不存在", 直接拦截

这一梳理,让我对缓存相关的问题,有了一个清晰、不再混淆的全景认识。缓存的"三大经典坑"——雪崩、击穿、穿透,它们听起来相似,根因却各不相同,必须分清:缓存雪崩(我这次的坑)是"大量 key 同时失效",解法是"过期时间加随机 + Redis 高可用 + 多级缓存"。缓存击穿是"单个超热点 key 失效瞬间被大量请求穿透"——它和雪崩的区别在于"一个 vs 大量"，解法是用"互斥锁"让只有第一个请求去重建缓存、其它请求等待,或者让热点 key"逻辑过期、后台更新"。缓存穿透则完全不同——它查的是"根本不存在的数据"(常见于恶意攻击,比如一直查 id=-1),因为数据库里查不到、缓存里也永远建不起来,每次都打到数据库;解法是"把空结果也缓存起来",或用"布隆过滤器"快速拦截掉那些一定不存在的查询。理解了这三者的区别,我才算真正建立起了对'缓存这道保护层,会以哪几种方式失守'的全面认知——而知道它会怎么失守,正是设计一个'稳固的、不会轻易被击穿的'缓存保护层的前提。

第四件事:更系统地"加固缓存保护层"——多重防御

"过期时间加随机"治好了我这次的雪崩,但我想得更深一层:一个真正高可用的缓存架构,不能只靠这一招,而应该有多重防御,以应对各种可能的"保护层失守"。我把这套"加固缓存保护层"的多重防御手段,整理了一遍:

加固缓存保护层的多重防御手段:

# 防御1: 过期时间加随机 (防雪崩 - 同时过期, 本文)
ttl = base + random(0, jitter)

# 防御2: Redis 高可用 (防雪崩 - 缓存层整体宕机)
#   Redis 主从 + 哨兵 / 集群, 别让"单点 Redis 挂了"导致缓存全没。

# 防御3: 互斥锁 / 逻辑过期 (防击穿 - 热点 key 失效瞬间)
#   只让一个请求去重建缓存, 其它请求等待或用旧值。

# 防御4: 缓存空值 + 布隆过滤器 (防穿透 - 查不存在的数据)
#   把"不存在"也缓存住, 或用布隆过滤器提前拦截。

# 防御5: 多级缓存 (本地缓存 + Redis)
#   在 Redis 前再加一层"本地内存缓存"(如 Caffeine),
#   即使 Redis 抖动/失效, 本地缓存还能挡一部分, 多一层保险。

# 防御6: 限流 + 降级 (最后的兜底防线!)
#   万一缓存还是失守了, 用"限流"控制打到数据库的流量(超过阈值就拒绝),
#   用"降级"返回兜底数据(如默认值/旧数据), 保护数据库不被打死。
#   → 限流降级, 是"保护数据库"的最后一道防线, 即使前面全失守, 它也能兜住。

# 防御7: 缓存预热 + 不让缓存过期(对极热数据)
#   极热的、几乎不变的数据, 可以"永不过期" + 后台定时刷新, 从根上没有"失效瞬间"。

核心思想: 缓存保护层, 不能是"单薄的一道墙",
  而应是"层层设防的纵深防御"—— 一层失守, 还有下一层兜着。

这套"多重防御",让我对"如何构建一个稳固的缓存架构",有了体系化的认识。它的核心思想,是"纵深防御"——不把希望寄托在单一的一道防线上,而是层层设防,让每一种可能的"失守",都有对应的、且不止一道的防御来应对。防御1、2针对雪崩(过期随机化、Redis 高可用),防御3针对击穿(互斥锁),防御4针对穿透(空值缓存、布隆过滤器)——这是针对三大经典坑的"对症防御"。而防御5、6、7,则是更高层次的'兜底防御':多级缓存(本地缓存 + Redis)多加一层保险;缓存预热 + 极热数据永不过期,从根上消除"失效瞬间";而最关键的,是防御6——限流 + 降级,这是"保护数据库"的最后一道防线:万一前面所有的缓存防御都失守了,限流能控制住打到数据库的流量(超过阈值就直接拒绝部分请求)、降级能返回一个兜底的结果(默认值或旧数据),从而确保——哪怕缓存全线崩溃,数据库这个'根基'也绝不会被打死。把这套多重防御和它们各自的职责整理成一张表:

第五件事:看清这一切背后的"流量洪峰"思维

这次踩坑,让我把视野从"缓存"拉高到了一个更本质的命题——"如何应对流量洪峰"。我意识到,缓存雪崩,本质是一种"流量洪峰"问题;而应对洪峰,有一套相通的、跨越具体技术的思维:

"应对流量洪峰"的通用思维(不止于缓存):

  缓存雪崩, 本质是: 一个"瞬间的、集中的流量洪峰", 打垮了后端。
  而应对一切"洪峰", 思路无非这几类:

  1. 削峰填谷: 把"集中的"变成"分散的"
     - 缓存过期时间加随机(本文): 把集中失效, 分散成陆续失效
     - 消息队列削峰: 请求先入队, 后端按自己的节奏慢慢消费
     - 错峰调度: 别让定时任务都在整点跑

  2. 分流泄洪: 把"集中到一处的"分散到多处
     - 多级缓存、读写分离、分库分表、CDN
     - 让流量被多个层级/节点分担, 别都挤向一个点

  3. 限流闸门: 控制"进来的流量"不超过承受能力
     - 限流: 超过阈值就拒绝, 保护后端在容量内运行

  4. 弹性扩容: "洪峰来了, 就加大河道"
     - 自动扩容, 临时增加处理能力

  5. 兜底降级: "实在扛不住, 保核心、弃次要"
     - 降级非核心功能, 返回兜底数据, 保住核心可用

核心: 任何系统, 都有它的"承受上限";
  而"流量洪峰", 就是对这个上限的冲击。
  应对之道, 要么"削平洪峰"(让冲击变缓), 要么"加固河道"(提升上限),
  要么"控制入水"(限流), 要么"弃车保帅"(降级)。

这个升华,让我对"缓存雪崩"的理解,从"一个具体的缓存问题",上升到了"一类'流量洪峰'问题"。缓存雪崩,本质上,就是"一个瞬间的、集中的流量洪峰,冲垮了承受能力有限的后端";而应对一切'流量洪峰'的思维,是相通的、可迁移的。"削峰填谷"(把集中变分散)——我这次的"过期时间加随机"就是它,而消息队列削峰、错峰调度也是同一思想。"分流泄洪"(把集中到一处的分散到多处)——多级缓存、读写分离、分库分表、CDN,都是让流量被多个节点分担。"限流闸门"(控制进来的流量)、"弹性扩容"(加大处理能力)、"兜底降级"(保核心弃次要)——则是应对洪峰的其它几种通用招式。看清了这一层,我就不再把"缓存雪崩"当成一个孤立的、需要死记解法的问题,而是把它放进了'如何应对流量洪峰'这个更大的思维框架里——而一旦掌握了这套'削峰、分流、限流、扩容、降级'的通用思维,我面对任何'瞬间洪峰冲击系统'的问题(无论是缓存、是秒杀、是热点、是定时任务),都能从这套框架里,找到应对的方向。把这套应对洪峰的通用思维和缓存场景的对应整理成一张表:

一张"缓存保护层怎么设计"的决策图

把这次踩坑沉淀成一张图。设计一个缓存方案时,照着它把防御补全:

这张图把缓存防御串成了一条流水线:过期时间一律加随机(防雪崩)→ 有热点 key 就加互斥锁(防击穿)→ 可能查不存在的就缓存空值/布隆过滤器(防穿透)→ Redis 高可用+多级缓存纵深加固 → 最后限流降级兜底。把这条流水线变成设计每个缓存方案的标准动作,缓存的几大经典坑就都被你挡在了门外。

我立下的几条缓存设计规矩

这次"整点缓存雪崩"的事故后,我给自己立了几条规矩:

1. 过期时间必加随机:批量设置缓存的过期时间,一律加随机偏移,让它们错峰失效,绝不用统一 TTL。
2. 分清雪崩/击穿/穿透:清楚三者的不同成因,设计时针对性地都防到。
3. 热点 key 防击穿:超热点 key 用互斥锁或逻辑过期,避免失效瞬间被大量请求穿透。
4. 防穿透:可能被查不存在数据的场景,缓存空值或用布隆过滤器拦截。
5. 缓存层要高可用:Redis 用主从/集群,别让单点宕机导致缓存全失效;重要场景加多级缓存。
6. 限流降级兜底:把限流 + 降级作为保护数据库的最后一道防线,确保缓存全失守时数据库也不被打死。
7. 用洪峰思维审视:用"削峰、分流、限流、扩容、降级"的洪峰思维,系统地审视高并发设计。

这几条里,第一条"过期时间必加随机"是用一次整点雪崩换来的、最该刻进肌肉记忆的铁律。而贯穿所有规矩的那条主线,是对"集中"与"分散"的敏感。我这次栽这么大跟头,根子上是我无意中制造了一个"高度集中"的事件——让上万条缓存,集中在同一时刻失效。而'集中',在高并发系统里,往往是危险的:集中的失效、集中的请求、集中的写入、集中的定时任务……任何'大量同类事件在同一时刻集中爆发'的情况,都可能形成一个瞬间的洪峰,冲垮系统某个承受能力有限的环节。反之,'分散',则往往是安全的:把集中的事件,在时间上、在空间上分散开,洪峰就被削平成了细流。对'集中'保持警惕、主动地用'随机化、错峰、分流'等手段去'分散'它,是设计高并发系统时一种重要的本能。

写在最后:危险,往往藏在"过于整齐"之中

这次被缓存雪崩教育的经历,给我一个颇具哲理的启示:在很多系统里,'过于整齐''高度同步''完全一致',非但不是好事,反而恰恰是危险的来源;而适当的'随机''参差''错落',看似不那么'完美',却往往是系统稳定与健壮的保障。我给所有缓存设一个"整齐划一"的过期时间,出发点甚至可以说是"追求一致、追求规整"的——可正是这份"过于整齐",让它们整整齐齐地同时失效,酿成了雪崩。而我只是给它加了一点"不那么整齐"的随机偏移,让它们的失效时间变得"参差错落",雪崩就消失了。这个看似微小的对比里,藏着一个深刻的道理:在一个需要承受冲击、需要削峰填谷的系统里,'整齐'意味着'同步',而'同步'意味着'共振'——大量的事件同步发生,会叠加成一个谁也扛不住的巨大峰值;而'参差'意味着'错开',错开的事件,峰值被自然地摊平、化解。

想通这一点,我对"随机性"和"多样性"在系统中的价值,有了全新的认识。我们工程师,常常本能地追求"确定""一致""整齐"——这在很多时候是对的(比如代码风格、接口规范)。可在另一些时候,尤其是在面对'大规模、高并发、需要抗冲击'的场景时,刻意地引入一点'随机''打散''多样',反而是一种更高级的智慧——它用一点点'不确定',换来了系统整体的'稳定';用一点点'不那么整齐',换来了系统对冲击的'韧性'。这种思想,在自然界、在工程里,其实无处不在:生物的多样性,让物种更能抵御灾难(整齐划一的单一物种,一场瘟疫就可能全军覆没);电网的错峰用电,避免了用电高峰的崩溃;甚至连分布式系统里的"重试",都要加"随机退避(jitter)",以避免所有失败的请求,在同一时刻整齐地、又一次地、共振式地重试,造成二次冲击。'用随机打破同步、用参差化解共振',是一种值得我们在设计系统时反复体会的、深刻的智慧。

所以,如果你也在设计需要承受规模与冲击的系统,我想把这次踩坑最想说的话送给你:请对系统里那些'过于整齐、高度同步'的地方,多一份警惕;并学会在恰当的时候,主动地引入一点'随机'与'参差',去打破那种危险的'共振'。大量缓存别设同一个过期时间,加点随机;大量定时任务别都挤在整点,错开调度;大量重试别都同时发生,加随机退避;大量请求别都涌向一处,分流打散。因为在规模的世界里,'整齐划一的同步',往往是埋藏着的、共振式的危险;而'恰到好处的参差与随机',则常常是化解这种危险、赋予系统韧性的、那剂朴素而有效的良药。那场由"过于整齐的过期时间"引发的雪崩,最终教给我的,正是这份对"整齐之危、参差之智"的体悟——它让我懂得,设计一个能扛住冲击的系统,有时不是要追求极致的一致与同步,反而是要懂得,在恰当的地方,撒上一把打破同步的、化解共振的"随机的盐"。

—— 别看了 · 2026