-
我给一批缓存数据统一设了一小时过期、平时缓存命中率高得很数据库压力很小,可每隔整整一小时数据库就会突然被海量请求瞬间打垮、CPU 飙满响应超时,排查很久才惊觉那批缓存是同一时刻批量写进去的、于是又在同一时刻集体失效把流量齐刷刷地全砸向了数据库的深度复盘
我的系统在缓存里存了一大批热点数据(商品信息、配置项),为了定期刷新给每条都设了 TTL=1 小时,平时跑得非常好:绝大多数请求命中缓存根本不碰数据库、DB 的 QPS 低得可怜监控一片祥和。可诡异的事周期性发生:每隔大约一小时数据库就突然遭遇一波海量查询、QPS 瞬间冲到平时几十倍、CPU 打满连接池占爆大量超时,持续几秒到十几秒恢复、下个整点再来一次。我怀疑整点跑批(没有)、怀疑有人整点刷接口…- 0
- 0
-
我给接口加了限流、限定每分钟最多 600 次以为稳了,大促时下游服务还是被瞬间打爆雪崩,我反复确认限流配置数字没错、监控里平均 QPS 也没超百思不得其解,最后才发现是我用的固定窗口计数器在每分钟切换那一瞬间放进了两倍流量的深度复盘
我的服务前面挡着一层限流:统计每分钟进来多少请求、超过 600 个就拒绝、下一分钟清零重数,我对它很放心。可大促当晚下游连接池瞬间被占满、超时、连锁雪崩,而限流明明开着。我盯监控,每分钟请求量几乎都贴着 600 的线没哪分钟超过,拒绝计数也在涨说明它确实在拦,可下游就是被打爆了。我怀疑下游容量缩水、怀疑配置被改大,都没有。直到把被打爆那一刻精确到秒的请求时间戳拉出来按秒画图才倒吸凉气:某一分钟最后…- 0
- 0
-
一个被高频访问的热点缓存恰好过期的那一瞬间,几千个请求同时扑向数据库去重建它,瞬间把数据库打垮了:一次缓存击穿、热点 key 过期空窗的深度复盘
我有个被高频访问的热点数据放在缓存里、设了 5 分钟过期,平时读缓存命中一切顺滑。可某次监控突然报警数据库 CPU/连接数瞬间飙满、差点雪崩,恰好发生在那个热点缓存过期的那一刻。复盘那一瞬间才明白这是缓存击穿:那个 key 被每秒几千请求高频访问,当它到点过期从缓存消失的瞬间,几千个并发请求同时发现未命中、几乎同时全部扑向数据库去查数据重建缓存,本该由缓存挡住的几千 QPS 在这一瞬间全砸到数据库…- 0
- 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
-
一个 Redis 分布式锁的过期时间没扛住业务耗时,锁提前自动释放让两个线程同时进了临界区、还互相误删了对方的锁:一次分布式锁失效的深度复盘
用 Redis 分布式锁保证同一笔账只有一个节点处理,跑了大半年都好好的,直到对账量大、业务跑了 40 秒、超过了锁的 30 秒过期时间——锁中途自动释放,第二个线程进了临界区两线程同时处理,第一个线程干完 del 又删掉了第二个线程的锁,锁彻底形同虚设。本文讲透分布式锁的两大核心难题(过期时间两难、误删),给出唯一标识+Lua 原子校验删除防误删、看门狗自动续期解决过期、生产用 Redisson…- 0
- 0
-
一个超热点的商品缓存在过期那一瞬间,成千上万的请求同时涌向数据库去重建它,把 DB 瞬间打垮,我对着缓存击穿这个热点 key 过期引发的惊群效应排查了大半天的复盘
一个让我对缓存不是万能挡箭牌彻底清醒的架构坑,诡异在平时缓存把 DB 保护得很好负载很低,可某个特定瞬间 DB 会突然遭受排山倒海的并发冲击而崩溃——而这瞬间恰是某个最热门的缓存刚好过期那一刻。系统用 Redis 缓存商品详情设 1 小时过期,DB 监控却毫无规律间歇性出现瞬时高负载连接打满。代码是标准的读缓存没有就查 DB 回填。隐患在并发:一个爆款商品每秒上万请求,缓存过期那一瞬间这上万并发几…- 0
- 0
-
我给系统加了 Redis 缓存本以为高枕无忧,大促零点却被缓存集体失效瞬间打垮了数据库,我对着缓存雪崩、击穿、穿透排查了大半天的复盘
第一次扛大促,我提前给核心查询都加了 Redis 缓存,自测命中率很高、DB 压力很小,信心满满以为"有缓存挡着数据库稳如泰山"。零点一过监控就疯狂告警:数据库 CPU 瞬间打满、连接池耗尽、接口大面积超时,缓存命中率从 98% 断崖跌到 30%,DB QPS 几乎垂直拉到 18000+。排查大半天才把三个名字相近、根却不同的缓存失效问题彻底搞明白:雪崩(我给所有 key 设了…- 0
- 0
-
我给热点数据加了缓存,本以为能稳稳扛住流量、高枕无忧,结果缓存一过期,成千上万的请求在那一瞬间全砸到了数据库、把它直接压垮的深度复盘
我给热点数据加了 Redis 缓存,数据库压力一下就下来了,很满意。可某天高峰,数据库突然被打挂。不是有缓存挡着吗?盯监控复盘才发现:数据库挂掉恰好在那个热点缓存"过期"的一瞬间——这是经典的缓存击穿。热点 key 过期那一刻缓存突然没了,而此时正有上万并发在访问它,它们同时未命中、同时涌向数据库,瞬间把库压垮;第一个请求还没回填好,后续继续砸库,恶性循环。我只享受了缓存命中时…- 0
- 0
-
整点一到,数据库 CPU 瞬间飙满、全站雪崩:我给所有缓存设了同一个过期时间,亲手制造的那场每小时定时引爆的缓存雪崩事故复盘
服务每到整点,数据库 CPU 就从十几瞬间飙到 100%、全站卡顿,过一两分钟又自愈。盯了好几个整点才发现:每次飙升瞬间数据库查询量暴增几十倍——缓存集体失效了。根因是我预热缓存时给上万条数据设了完全相同的 3600 秒过期时间,它们在同一时刻整齐过期,海量请求同时穿透、砸向数据库。这篇从缓存雪崩"同时失效"的本质讲到过期时间加随机的正解、雪崩/击穿/穿透三大坑、多重防御与限流…- 0
- 0
-
服务跑着跑着就报"cannot assign requested address",我以为是端口配置错了,真相却是几万个 TIME_WAIT 把端口耗光了的复盘
一个高频调用下游 HTTP 接口的服务,跑一段时间后开始报 dial tcp: cannot assign requested address。我以为是端口配置错,直到 netstat 一统计——近三万个 TIME_WAIT!根因是我为每个请求都新建 TCP 连接、用完就关,主动关闭方的连接进入 TIME_WAIT 停留 60 秒,每秒几百个累积起来,把本机约 2.8 万个临时端口占光了。这篇从 …- 0
- 0
-
端口被 TIME_WAIT 占满:TCP 短连接避坑复盘
这次事故的报错信息第一眼看上去毫无道理:我们一个服务在流量高峰期偶发性地报一个奇怪的错误 Cannot assign requested address 无法分配请求的地址。我盯着这行错误懵了好一会儿:分配地址?我又没在创建什么地址,我只是在调用一个下游的 HTTP 接口而已啊,而且这个错误只在高峰期出现,服务器的 CPU 内存带宽也都不紧张,一个资源充裕的服务器却报无法分配地址,这到底是什么玄学…- 0
- 0
-
缓存集体过期压垮数据库:雪崩击穿穿透避坑
一次让我记忆犹新的线上雪崩:服务前面挡着一层 Redis 缓存,绝大多数读请求都打在缓存上,数据库平时悠闲得很。某天上午十点整监控突然炸了,数据库 CPU 瞬间飙到 100%、响应从几毫秒蹦到几秒、大量请求超时、整个服务几乎瘫痪,可流量并没暴涨多少,就是平日水平。盯着曲线复盘才发现一个关键巧合:故障爆发的十点整,正是前一天凌晨批量预热缓存的那批数据集体到期的时刻——那批缓存头天同一时间一次性灌进 …- 0
- 0
-
大促后对账发现重复扣款:一篇讲透接口幂等性设计
大促结束后的第二天上午,财务一条"对账对不平、几十个用户被重复扣款"的消息把我从复盘的轻松里一把拽出来,更夸张的是有人同一笔订单在库里躺着三四条记录。复盘下来真相平淡得后背发凉:流量冲顶时下单接口变慢,用户疯狂连点,客户端和网关又都配了超时重试,同一个请求被结结实实送进后端好几遍——而整个下单链路没有任何一处做了幂等保护。这篇文章从那次重复扣款事故出发,把接口幂等设计从头讲透:…- 8
- 0
-
缓存三连击实战:穿透、击穿、雪崩,一个热点 key 如何打挂数据库
那次大促,数据库 CPU 垂直拉到 100%、接口大面积超时、上游服务跟着雪崩,我们第一反应是扩容却根本来不及。复盘才发现根因小得哭笑不得:一个被几万人盯着的热点商品缓存恰好在那一刻过期了——几万并发瞬间穿过缓存把同一条查询砸了几万次,这就是缓存击穿。这篇从这个一个 key 打挂数据库的事故讲起,把缓存三大杀手穿透、击穿、雪崩怎么区分、各自怎么治讲透:singleflight 与分布式锁防击穿、空…- 4
- 0
-
订单系统抗大促架构演进:异步削峰、库存预扣、服务拆分与最终一致性
那年第一次参加大促,我们的订单系统在活动开始后第四分钟就崩了:下单成功率从 99% 直线跳水到不足 30%,数据库连接瞬间打满、CPU 飙到 100%,连商品详情、购物车这些跟下单八竿子打不着的页面也跟着转圈(因为共用一个库被一起拖下水),事后还清出上百个超卖订单要连夜退款道歉,几个人守到凌晨三点才勉强稳住。复盘结论很清楚:不是机器不够,是架构扛不住瞬时洪峰——一个平时跑得好好的同步串行单体,在「…- 2
- 0
-
从粗放 MySQL 交易库 @Transactional 包住整个大方法连远程支付调用都裹进事务里行锁被慢接口绑架数秒高峰锁等待瀑布堆积连接池占满雪崩 + 压根不懂隔离级别用默认或乱设脏读不可重复读幻读分不清还把快照读和 FOR UPDATE 当前读混用读出灵异结果 + 凡是更新就无脑 select for update 悲观锁把读多写少场景的并行更新硬串行化 + 加锁顺序五花八门死锁频发只能靠重启清场 + 更新条件不走索引 InnoDB 行锁退化成扫描路径锁住一大片甚至全表把无关更新全阻塞 + 热点大商家账户单行被每秒上万笔成交更新行锁让请求排成长龙吞吐卡死 + 库存扣减用裸 read-modify-write 并发下丢失更新导致严重超卖发不出货 + 大事务循环更新几万行跑几分钟持锁堆 undo 拖慢全库还有僵尸事务赖着不走 + 锁等待死锁长事务全是黑盒出事才 SSH 上去 show processlist 肉眼抓瞎 → 2026 现代高并发数据库工程 短事务只包必须原子的 DB 写远程调用挪到事务外 + 理解四个隔离级别权衡默认 RR 分清 MVCC 快照读当前读 + 读多写少用乐观锁版本号 CAS + 统一按主键升序加锁加死锁监控加自动重试 + 写条件必走索引 EXPLAIN 确认行锁精准只锁命中行 + 热点账户余额分桶拆成多行分散并发读时 SUM 合并 + 原子 UPDATE x=x±? 加 stock>=1 条件根治丢失更新和超卖 + 批量拆成分批小事务加长事务监控告警 + performance_schema 持续度量锁等待和长事务做大盘告警 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
8 人的数据库与交易平台团队 87 天把一套跑了五年、日订单量从每天几十万笔涨到上千万笔、大促高峰每秒上万笔并发写入后种种粗放并发写法集中爆雷的核心交易数据库——@Transactional 习惯性地甩在最外层大方法上把查库改库远程支付调用发消息发短信统统圈进同一个事务里一次慢支付就让账户行锁被绑架数秒高峰期锁等待瀑布式堆积连接池被长事务占满整个交易服务超时雪崩、压根不懂事务隔离级别要么手欠调到串…- 5
- 0
-
从粗放 Go 微服务裸 go 无限开 goroutine 泄漏暴涨几十万 OOM + 无 context 传递被慢下游拖垮全链路无限干等堆积雪崩 + err 被 _ 丢掉漏接出错不知哪层报的 + 滥用 panic 当错误处理没 recover 一个边角崩整个进程 + 共享变量裸读写 data race 偶发脏数据和 concurrent map writes 崩溃 + interface{} 加类型断言丢类型安全运行时动不动 panic + 手撸 WaitGroup 加 error channel 协调并发又长又易错死锁漏收 + 热点频繁分配小对象 GC 压力大 STW 停顿肉眼可见 + 线上黑盒哪慢哪漏全靠猜 + 部署直接 kill 硬断在途请求连接 → 2026 现代高并发 Go 工程 worker pool 受控并发加 context 退出 + context 全链路传递超时取消 + 显式 error 加 %w wrapping 加 errors.Is/As + Mutex/atomic/channel 保护加 -race 检测 + 泛型 type-safe 编译期保证 + errgroup 统一并发错误取消 + sync.Pool 复用减少逃逸 + pprof/trace/metrics 可观测 + signal 加 context 优雅关闭 drain 排空 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
10 人的 Go 基础设施与后端团队 87 天把一套用了四年、流量从每秒几千涨到每秒几十万后种种粗放并发写法集中爆雷的 Go 微服务集群——到处是裸 go 启动 goroutine 不加任何数量限制也没有退出机制高峰期 goroutine 暴涨到几十万 OOM、很多 goroutine 因为在阻塞 channel 上永远等不到信号而悄无声息泄漏越积越多、请求链路上完全没有 context 传递一个…- 4
- 0
-
从粗放 Node.js 服务 error-first 回调层层嵌套成七八层回调地狱读不懂改不动 + 同步阻塞 IO 和 CPU 密集计算把单线程事件循环死死卡住全请求被拖死超时 + CommonJS require 同步加载无法 tree-shake 产物臃肿 + error 被吞掉漏写 catch 未捕获 reject 直接崩进程 + Promise.all 一把梭几千请求无限并发瞬间打爆下游雪崩 + 大文件大响应一次性全读进内存 Buffer 暴涨 OOM + event listener 不解绑缓存无上限内存像漏水的桶涨到 OOM 重启 + 单进程只占一核其余核心全闲置浪费 + 满地撒 console.log 海量无结构日志大海捞针 → 2026 现代高性能后端 async/await 扁平化顺序读写 + 异步 IO 加 worker_threads 卸载 CPU 密集主线程畅通 + ESM import 静态可摇树 + 统一 try-catch 加错误中间件加 process 兜底 + p-limit 并发上限保护下游 + Stream 流式 pipeline 背压内存平稳 + 解绑加 WeakMap 加 LRU 上限治理内存 + cluster 多进程多核负载均衡 + pino 结构化日志加请求 id 全链路追踪 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
11 位 Node.js 后端工程师 87 天把一套跑了五年、业务量从每天几万请求涨到几千万请求后种种粗放写法集中爆雷的 Node.js 服务集群——大量异步逻辑用 error-first 回调一层套一层嵌套成七八层深的回调地狱金字塔加个错误处理都要每层重复写读都读不懂、有些地方图省事用 readFileSync 同步阻塞 IO 还有几处把 CPU 密集计算直接放主线程跑结果一个请求就把整个单线程…- 0
- 0
-
Go 1.22 gRPC 推送网关 P99 从 45ms 飙到 6.2 秒的 6 天并发雪崩复盘:map 并发读写 + channel 缓冲不足 + 单 Mutex 三重叠加 + 11 条 Go 并发纪律
我们一个 Go 1.22 + gRPC 推送网关,单 Pod 维护 60 万长连接、推送 QPS 280 万,在压测中 P99 从 45ms 飙到 6.2 秒,部分 Pod 被 K8s 重启,直播弹幕延迟 6 秒收 3000 工单。6 天定位发现 map 并发读写触发 throw + channel 缓冲不足 + 单 Mutex 保护 60w-entry 大 map 三重反模式叠加。修复路径分片 …- 2
- 0
-
Nginx 性能调优与超大并发完全指南:从一次"直播开播 5 分钟 worker_connections 1024 撞墙全站 502"看懂为什么 apt install nginx 远远不够
2023 年我们做一个直播弹幕推送系统业务量从 1 万 QPS 涨到 30 万 QPS 用 Nginx 做反代加静态资源加 WebSocket upgrade 第一版直接 apt install nginx 改个 server_name 就上线老板说 Nginx 这么稳直播开播 5 分钟 Nginx 直接 502 全站崩第一种最让我傻眼是 worker_connections 默认 1024 30…- 0
- 0
-
Redis 缓存设计完全指南:从一次"主播开播 10 万人涌入缓存击穿 MySQL 5 分钟挂掉"看懂为什么 SET GET 远远不够
2021 年我在一家社交 App 公司负责后端用 Redis 做缓存层 20 多个微服务都接它第一版我们就 Set Get 用得很爽大家觉得 Redis 是银弹啥都可以缓存然后业务起飞日活 500 万缓存层就开始陆续出问题一周内连续两次大面积故障缓存击穿缓存雪崩缓存穿透全踩了一遍然后我们陆续踩了一堆坑第一种最让我傻眼一次热门主播开播 10 万人涌入查他的资料主播缓存刚好过期 10 万请求同时打到 …- 2
- 0
-
Nginx 性能调优完全指南:从一次"30 万 QPS 促销 502 满天飞 CPU 跑满 30 分钟"看懂为什么默认配置远远不够
2021 年我加入一家短视频公司接手 API 网关用 Nginx 做反向代理后端 50 个微服务日常 QPS 5 万高峰 20 万第一版我用 Nginx 默认配置装好就上业务跑了半年没事直到一次促销活动流量瞬间冲到 30 万 QPS Nginx CPU 100% 大量 502 用户疯狂吐槽老板半夜把我电话打爆然后我们陆续踩了一堆坑第一种最让我傻眼 worker_processes 默认 1 单核跑…- 5
- 0
高并发
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×