-
我给一批缓存数据统一设了一小时过期、平时缓存命中率高得很数据库压力很小,可每隔整整一小时数据库就会突然被海量请求瞬间打垮、CPU 飙满响应超时,排查很久才惊觉那批缓存是同一时刻批量写进去的、于是又在同一时刻集体失效把流量齐刷刷地全砸向了数据库的深度复盘
我的系统在缓存里存了一大批热点数据(商品信息、配置项),为了定期刷新给每条都设了 TTL=1 小时,平时跑得非常好:绝大多数请求命中缓存根本不碰数据库、DB 的 QPS 低得可怜监控一片祥和。可诡异的事周期性发生:每隔大约一小时数据库就突然遭遇一波海量查询、QPS 瞬间冲到平时几十倍、CPU 打满连接池占爆大量超时,持续几秒到十几秒恢复、下个整点再来一次。我怀疑整点跑批(没有)、怀疑有人整点刷接口…- 0
- 0
-
我们的 AI 功能上线第一个月,大模型 API 账单直接爆了十几倍,我一查才发现每个请求都在拿最贵的模型、塞着超长 prompt、重复算同样的东西的深度复盘
我们给产品加了个 AI 功能,上线时测着没问题,可一个月后大模型 API 账单比预估高了十几倍,财务来问钱花哪了。拉日志分析才明白:我完全没把调用大模型要花钱、按 token 计费这件事放在心上,代码里堆了一堆烧钱写法——所有请求不分难易都用最贵的旗舰模型(贵几十倍)、prompt 塞着大段背景和全量文档每次原样发(输入 token 大)、完全相同的请求每次都重新调一遍(不缓存)、没设 max_t…- 2
- 0
-
用户明明改了资料、刷新却还是旧的,排查发现是我更新数据库后顺手更新缓存在高并发下把旧值写回了缓存:一次缓存与数据库双写一致性、Cache-Aside 该删缓存而非更新缓存的深度复盘
我们的用户资料服务为扛读量加了 Redis 缓存,读走缓存未命中查库回填,写用我自以为周到的先更新数据库再顺手更新缓存。功能测着没问题,线上却偶发:用户改了资料、缓存却长期是旧值,刷不新直到过期才好。在并发场景下推演才看明白:更新库和更新缓存两步非原子,两个并发写请求 A、B 都先更库再更缓存,DB 最终是 B 的新值(对),但更新缓存时因线程调度 B 先写、A 后写,缓存被覆盖回 A 的旧值——…- 0
- 0
-
一个先更新数据库再删缓存的常规缓存写法,在一次并发读写恰好交错时,把旧数据又写回了缓存、脏了好久:一次缓存一致性的深度复盘
用 cache-aside(先更新数据库再删缓存)缓存商品,偶尔出现 DB 是新价、缓存却一直是旧价。根因是读写并发交错:缓存刚过期时读请求查 DB 读到旧值、还没回填,此时写请求更新 DB 并删缓存,然后读请求慢一步把旧值写回缓存、盖过了写的删除,缓存就脏到下次过期。本文讲透缓存和 DB 是两个独立存储、双写非原子、任何纯双写都有交错会不一致,给出 cache-aside+TTL 兜底(最关键)…- 0
- 0
-
一个只缓存查得到的数据的接口,被人用大量不存在的 ID 反复查询,缓存形同虚设、请求全砸到数据库上,差点把库打垮:一次缓存穿透的深度复盘
商品详情接口前面挡着 Redis,平时 DB 压力很小,某天 DB QPS 突然暴涨几十倍、缓存命中率却跌到 0。抓参数一看,请求查的全是不存在的随机 ID。根因是 cache-aside 只缓存查得到的非空结果:查不存在的 ID 时缓存没有、DB 也查不到、null 又不写缓存,于是每次都必然穿透直达 DB,被海量不存在 ID 攻击就把库打垮——这就是缓存穿透。本文讲透穿透与击穿、雪崩的区别,给…- 0
- 0
-
一个 JVM 服务因为默认永久缓存了 DNS 解析结果,在下游域名切换 IP 后还死连着早已下线的旧地址,连接全失败:一次 DNS 缓存的深度复盘
下游第三方做机房迁移,把域名解析到新 IP、旧 IP 下线,域名没变我们本该无感,结果服务大面积连接失败,而服务器上 nslookup 查的是新 IP、重启服务就好了。根因是 JVM 有独立于 OS 的 DNS 缓存,networkaddress.cache.ttl 默认可能是 -1(永久缓存)——进程首次把域名解析成旧 IP 后就永久记住、再也不重新解析,下游换 IP 后还死连旧地址、不重启不自…- 2
- 0
-
一个超热点的商品缓存在过期那一瞬间,成千上万的请求同时涌向数据库去重建它,把 DB 瞬间打垮,我对着缓存击穿这个热点 key 过期引发的惊群效应排查了大半天的复盘
一个让我对缓存不是万能挡箭牌彻底清醒的架构坑,诡异在平时缓存把 DB 保护得很好负载很低,可某个特定瞬间 DB 会突然遭受排山倒海的并发冲击而崩溃——而这瞬间恰是某个最热门的缓存刚好过期那一刻。系统用 Redis 缓存商品详情设 1 小时过期,DB 监控却毫无规律间歇性出现瞬时高负载连接打满。代码是标准的读缓存没有就查 DB 回填。隐患在并发:一个爆款商品每秒上万请求,缓存过期那一瞬间这上万并发几…- 0
- 0
-
我用 == 比较两个 Integer,小数值时一切正常,某天数值一超过 127 判断就突然失效了,我对着 Java 自动装箱的 Integer 缓存只缓存 -128 到 127 这个坑排查了大半天的复盘
一个堪称 Java 最阴险的坑之一,阴险在绝大多数测试数据下表现正常让你深信不疑,然后在某个数值恰好够大的真实场景里毫无征兆突然失效。我有两个 Integer 值要判断是否相等,图省事用了 ==。Integer a=100,b=100; a==b 是 true 看着没问题,测试用的都是小数值一切正常就上线了。可某天数值大了:Integer x=200,y=200; x==y 竟是 false！更精…- 0
- 0
-
我给系统加了 Redis 缓存本以为高枕无忧,大促零点却被缓存集体失效瞬间打垮了数据库,我对着缓存雪崩、击穿、穿透排查了大半天的复盘
第一次扛大促,我提前给核心查询都加了 Redis 缓存,自测命中率很高、DB 压力很小,信心满满以为"有缓存挡着数据库稳如泰山"。零点一过监控就疯狂告警:数据库 CPU 瞬间打满、连接池耗尽、接口大面积超时,缓存命中率从 98% 断崖跌到 30%,DB QPS 几乎垂直拉到 18000+。排查大半天才把三个名字相近、根却不同的缓存失效问题彻底搞明白:雪崩(我给所有 key 设了…- 0
- 0
-
我给热点数据加了缓存提速,结果用户改完资料刷新还是看到旧的、甚至并发改一下缓存就和数据库长期对不上,我对着这个缓存一致性问题排查了大半天的复盘
我给热点数据加了 Redis 缓存提速,结果用户改完资料、提示保存成功了,刷新还是旧数据;并发下偶尔缓存和数据库长期对不上、怎么刷都不对,只能手动清缓存。我加了"更新数据库后也更新缓存"反而更乱。把并发读写画在时间轴上才懂:缓存和数据库是两个独立系统、更新无法原子完成,中间总有不一致窗口,并发下交错就出问题;而我犯的典型错误是选了"更新缓存"而非"…- 0
- 0
-
我给热点数据加了缓存,本以为能稳稳扛住流量、高枕无忧,结果缓存一过期,成千上万的请求在那一瞬间全砸到了数据库、把它直接压垮的深度复盘
我给热点数据加了 Redis 缓存,数据库压力一下就下来了,很满意。可某天高峰,数据库突然被打挂。不是有缓存挡着吗?盯监控复盘才发现:数据库挂掉恰好在那个热点缓存"过期"的一瞬间——这是经典的缓存击穿。热点 key 过期那一刻缓存突然没了,而此时正有上万并发在访问它,它们同时未命中、同时涌向数据库,瞬间把库压垮;第一个请求还没回填好,后续继续砸库,恶性循环。我只享受了缓存命中时…- 0
- 0
-
缓存集体过期压垮数据库:缓存雪崩避坑复盘
那是一次教科书级别的雪崩:某个流量高峰的午间我们的服务突然开始大面积超时,告警短信像下雨一样砸进群里。我冲上去一看监控触目惊心——数据库 CPU 瞬间飙到 100%,慢查询日志疯狂刷屏,大量请求堆积超时,紧接着因为请求都卡在数据库上线程被占满,整个服务也跟着雪崩式瘫痪了。最诡异的是出事前流量并没有暴涨,就是平平常常的午高峰,怎么会在某一个瞬间突然就被打垮?排查结果是一个我们完全没意识到的定时炸弹:…- 0
- 0
-
缓存集体过期压垮数据库:雪崩击穿穿透避坑
一次让我记忆犹新的线上雪崩:服务前面挡着一层 Redis 缓存,绝大多数读请求都打在缓存上,数据库平时悠闲得很。某天上午十点整监控突然炸了,数据库 CPU 瞬间飙到 100%、响应从几毫秒蹦到几秒、大量请求超时、整个服务几乎瘫痪,可流量并没暴涨多少,就是平日水平。盯着曲线复盘才发现一个关键巧合:故障爆发的十点整,正是前一天凌晨批量预热缓存的那批数据集体到期的时刻——那批缓存头天同一时间一次性灌进 …- 0
- 0
-
缓存三连击实战:穿透、击穿、雪崩,一个热点 key 如何打挂数据库
那次大促,数据库 CPU 垂直拉到 100%、接口大面积超时、上游服务跟着雪崩,我们第一反应是扩容却根本来不及。复盘才发现根因小得哭笑不得:一个被几万人盯着的热点商品缓存恰好在那一刻过期了——几万并发瞬间穿过缓存把同一条查询砸了几万次,这就是缓存击穿。这篇从这个一个 key 打挂数据库的事故讲起,把缓存三大杀手穿透、击穿、雪崩怎么区分、各自怎么治讲透:singleflight 与分布式锁防击穿、空…- 4
- 0
-
从应用层手写字符串拼接 SQL 有注入风险 + 每次请求新建连接不复用 + 几乎不建索引查询全表扫描 + 循环里逐条查的 N+1 灾难 + 大事务长时间持锁 + 单库单表硬扛全部读写 + 没有慢查询监控不看执行计划凭感觉优化 古老数据库使用体系 → 2026 参数化预编译彻底防注入 + HikariCP 连接池化复用 + 合理索引与覆盖索引 + 批量查询消灭 N+1 + 清晰事务边界与乐观锁 + 读写分离与分库分表水平扩展 + 慢查询日志加 EXPLAIN 执行计划分析 + Redis 旁路缓存与穿透击穿雪崩防护 现代数据库工程体系 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
12 位 DBA 与后端工程师 87 天把一套跑了七年的粗放数据库使用体系——应用层手写字符串拼接 SQL 随时可能被注入脱库、每次请求新建连接不复用、几乎不建索引查询全表扫描、ORM 在循环里逐条查的 N+1 灾难、一个大事务包住一大堆操作长时间持锁让热点行排队、单库单表硬扛全部读写流量一大主库就 CPU 打满、没有慢查询监控不看执行计划全凭感觉瞎调——用在线 DDL 加双写灰度的稳健方式重构到…- 0
- 0
-
Redis 大 key 阻塞主线程导致集群级雪崩的复盘:18 分钟反复切换 + 5 种修法 + 9 条治理纪律
一次高价值用户标签 HGETALL 800MB 大 key 把 Redis 主线程阻塞 4.2 秒,Sentinel 误判反复切换 4 次,18 分钟内集群级雪崩。本文复盘完整排查过程、5 种修法(HSCAN/读 slave/分片/Sentinel 调参/SafeRedis 防护)、9 条治理纪律,以及 Redis 6.0 IO 多线程和持久化 fsync 的真相。- 10
- 0
-
Redis 缓存穿透/击穿/雪崩三大场景实战指南:从一次"大促零点缓存命中率从 98% 掉到 12%"看懂为什么 Redis 加 TTL 远远不够
2022 年我所在的电商团队做大促活动零点开抢的瞬间整个商品详情页接口的 RT 从平时的 80 毫秒飙升到了 8 秒缓存命中率从平时的 98% 掉到了 12% 我当时正在值班看着监控曲线直接懵了我们的缓存策略其实做得不算简单商品详情用 Redis 缓存了 TTL 半小时按理说大促前已经预热过了为什么命中率会掉这么狠后来复盘才发现这一夜爆出了不止一个问题第一个问题最常见某个爆款商品的缓存恰好在零点过…- 0
- 0
-
CDN 缓存完全指南:从一次"发了新版用户还看旧的、源站一挂整站全白"看懂 CDN 的正确用法
2022 年我做一个内容网站要给静态资源接入 CDN 加速。第一版我做得很省事把域名 CNAME 到 CDN 厂商配一个回源地址指向我的源站完事。本地和小流量下测了测真不错图片 JS CSS 加载肉眼可见地快了。我心里很踏实CDN 嘛把域名 CNAME 过去静态资源自动就走 CDN 加速了不就行了。可等这个网站真正上线扛起真实的用户流量一串问题冒了出来。第一种最先把我打懵我发布了一版新代码改了 C…- 0
- 0
-
一致性哈希完全指南:从一次"缓存集群加了一台机器、命中率瞬间归零"看懂分布式分片
2020 年我做一个分布式缓存。业务的读压力越来越大单台 Redis 扛不住了我决定加机器上 4 台 Redis 把缓存数据分散到这 4 台上。要解决的核心问题只有一个一个 key 进来我怎么决定它该存到该去哪一台机器上读。第一版我做得很直接把 key 算个哈希值对机器数取模算出 0 1 2 3 就去对应那台。本地一测很顺几百万个 key 均匀地散在 4 台机器上每台四分之一读写都飞快缓存命中率稳…- 0
- 0
-
缓存穿透、击穿、雪崩完全指南:从一次"加了 Redis,数据库还是被打挂"看懂缓存防护
2022 年我做一个电商的商品详情接口。这个接口 QPS 很高首页搜索推荐到处都在调它。第一版我直接查数据库压测一上量数据库 CPU 就飙红。我马上想到加缓存查商品时先查 Redis 有就直接返回没有再查数据库查完写回 Redis。这套旁路缓存加上去效果立竿见影数据库 CPU 应声降下来。我当时心里很踏实有缓存挡着数据库稳了。可上线之后数据库还是三番五次地被打挂每次现象还不一样。第一次有人在疯狂查…- 0
- 0
-
缓存穿透击穿雪崩完全指南:从一次"加了缓存数据库反而被打挂"看懂三大缓存问题
2020 年我维护一个商品详情服务,最初每个请求都直接查数据库,流量一大数据库就吃力。我给它加了一层 Redis 缓存:查询时先看缓存,命中就直接返回,没命中再查数据库、把结果写回缓存。上线后命中率稳定在 95% 以上,数据库负载降到原来的零头,我以为加了缓存数据库就高枕无忧了。可后来接连出过三次事故每次数据库都被打挂:第一次有人写脚本拿一堆不存在的商品 ID 狂刷,这些 ID 数据库查不到缓存也…- 0
- 0
-
Redis 缓存完全指南:从一次缓存雪崩看懂穿透、击穿、雪崩怎么防
2021 年我负责商品详情页后端,早早加了 Redis 缓存——先查 Redis 命中直接返回、没命中才查 DB 再写回,跑了大半年稳稳当当。直到某个大促日出事:数据库 CPU 干到 100%、大量请求超时、详情页大面积打不开,可 Redis 内存连接 CPU 全都健康。扒日志才看明白根因:图省事所有商品缓存过期时间统一设成 30 分钟,而这批商品是大促前用脚本集中预热进缓存的、几乎同一时刻写进 …- 0
- 0
-
一个热点 key 过期瞬间打挂数据库:一次 Redis 缓存击穿与雪崩穿透的复盘
一个爆款商品详情页一天几百万访问,商品信息做了缓存第一次查库后塞进 Redis 设一小时过期,上线后数据库负载稳得很,可某天起监控出现诡异的规律性抖动每隔约一小时数据库 CPU 毫无征兆瞬间飙到 100% 持续两三秒接口大面积超时然后自己恢复,周期恰好等于缓存过期时间。排查梳理:数据库被打挂第一刀先看它前面的缓存挡板还在不在,很多时候不是 DB 自己不行是挡板突然失效让本该被挡的流量全涌向 DB,…- 0
- 0
-
改了数据库,查出来还是旧的:一次 MyBatis 缓存踩坑的复盘
长事务里两次查同一条数据,第二次读到的还是旧值;后台改了配置接口却始终返回旧的,重启才好。根子是 MyBatis 一级缓存与二级缓存在帮倒忙。几天梳理:一级缓存作用域、长事务致脏、二级缓存跨表脏数据、集群不一致、为何生产建议关二级缓存改用 Redis。- 0
- 0
缓存
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×