-
我给接口加了"每分钟最多 100 次"的限流,结果它还是在某个瞬间被 200 次请求打穿了,我对着固定窗口限流的临界问题排查了大半天的复盘
给核心接口加限流保护,用了最直观的固定时间窗口算法——每分钟一个计数器超100就拒绝,以为每分钟最多100稳了。可一次流量高峰系统还是被打出问题,查监控发现诡异现象:某时间点附近一小段时间内接口竟处理了近200次,远超每分钟100。对着限流代码反复看计数器没错阈值也是100怎么放进200个?排查大半天才理解固定窗口限流隐蔽的临界问题(边界突刺):在两个窗口交界处可放进近2倍请求——某分钟后30秒来…- 0
- 0
-
我用 Redis 加了分布式锁防并发,结果两个进程还是同时执行了、还互相把对方的锁删了,我对着分布式锁的几个致命细节排查了大半天的复盘
做了个多实例部署的定时任务,用 Redis 加分布式锁确保同一时刻只有一个实例执行,以为加了锁就万事大吉。结果生产诡异:有时两个实例同时跑(锁没锁住)导致数据重复处理,有时一个实例把另一个实例的锁删了。盯着 SETNX 抢锁、DEL 释放的标准代码反复看,排查大半天才发现藏着三个致命细节:SETNX 没设过期(持锁者崩溃就死锁)、锁提前过期(业务跑40秒超过锁30秒过期,A还在执行B就抢到锁同时执…- 0
- 0
-
我给系统加了 Redis 缓存本以为高枕无忧,大促零点却被缓存集体失效瞬间打垮了数据库,我对着缓存雪崩、击穿、穿透排查了大半天的复盘
第一次扛大促,我提前给核心查询都加了 Redis 缓存,自测命中率很高、DB 压力很小,信心满满以为"有缓存挡着数据库稳如泰山"。零点一过监控就疯狂告警:数据库 CPU 瞬间打满、连接池耗尽、接口大面积超时,缓存命中率从 98% 断崖跌到 30%,DB QPS 几乎垂直拉到 18000+。排查大半天才把三个名字相近、根却不同的缓存失效问题彻底搞明白:雪崩(我给所有 key 设了…- 0
- 0
-
整点一到,数据库 CPU 瞬间飙满、全站雪崩:我给所有缓存设了同一个过期时间,亲手制造的那场每小时定时引爆的缓存雪崩事故复盘
服务每到整点,数据库 CPU 就从十几瞬间飙到 100%、全站卡顿,过一两分钟又自愈。盯了好几个整点才发现:每次飙升瞬间数据库查询量暴增几十倍——缓存集体失效了。根因是我预热缓存时给上万条数据设了完全相同的 3600 秒过期时间,它们在同一时刻整齐过期,海量请求同时穿透、砸向数据库。这篇从缓存雪崩"同时失效"的本质讲到过期时间加随机的正解、雪崩/击穿/穿透三大坑、多重防御与限流…- 0
- 0
-
一个用户被扣了三次款:我在架构设计里漏掉"幂等"这两个字,酿成的那场重复支付资损事故,以及如何为写接口铸上一道牢靠的防重的锁
客诉转来:用户只下了一单,银行卡却被连扣三次款。还原现场——他网络卡顿、不耐烦连点了三下支付,三个请求涌向服务端,而我的支付接口对"看起来一样、却不知道是重复"的请求各处理了一遍,扣了三次款。根因是我漏掉了分布式系统里至关重要的幂等性。这篇从幂等的本质、为什么写接口必须幂等,讲到唯一约束/token/状态机三种正解、判断与执行的原子性等魔鬼细节,以及幂等背后的防御性架构思维。- 2
- 0
-
大促后对账发现重复扣款:一篇讲透接口幂等性设计
大促结束后的第二天上午,财务一条"对账对不平、几十个用户被重复扣款"的消息把我从复盘的轻松里一把拽出来,更夸张的是有人同一笔订单在库里躺着三四条记录。复盘下来真相平淡得后背发凉:流量冲顶时下单接口变慢,用户疯狂连点,客户端和网关又都配了超时重试,同一个请求被结结实实送进后端好几遍——而整个下单链路没有任何一处做了幂等保护。这篇文章从那次重复扣款事故出发,把接口幂等设计从头讲透:…- 8
- 0
-
缓存三连击实战:穿透、击穿、雪崩,一个热点 key 如何打挂数据库
那次大促,数据库 CPU 垂直拉到 100%、接口大面积超时、上游服务跟着雪崩,我们第一反应是扩容却根本来不及。复盘才发现根因小得哭笑不得:一个被几万人盯着的热点商品缓存恰好在那一刻过期了——几万并发瞬间穿过缓存把同一条查询砸了几万次,这就是缓存击穿。这篇从这个一个 key 打挂数据库的事故讲起,把缓存三大杀手穿透、击穿、雪崩怎么区分、各自怎么治讲透:singleflight 与分布式锁防击穿、空…- 4
- 0
-
订单系统抗大促架构演进:异步削峰、库存预扣、服务拆分与最终一致性
那年第一次参加大促,我们的订单系统在活动开始后第四分钟就崩了:下单成功率从 99% 直线跳水到不足 30%,数据库连接瞬间打满、CPU 飙到 100%,连商品详情、购物车这些跟下单八竿子打不着的页面也跟着转圈(因为共用一个库被一起拖下水),事后还清出上百个超卖订单要连夜退款道歉,几个人守到凌晨三点才勉强稳住。复盘结论很清楚:不是机器不够,是架构扛不住瞬时洪峰——一个平时跑得好好的同步串行单体,在「…- 2
- 0
-
DDD 限界上下文划分错误导致 6 个月返工 420 人日的复盘:从按团队 / 按数据库表两次翻车到 Event Storming + 业务能力的正解 + 11 条划分纪律
我们用 240 人日做完一次 DDD 切分,然后 180 人日推倒重做。本文复盘 3 种 BC 划分方法的对比:按组织失败、按数据库失败、按业务能力 + Event Storming 才成功,以及 9 条引申认知。- 0
- 0
-
单表两亿行扛不住了:一次分库分表的复盘
orders 单表两亿行,加索引 DDL 卡几小时,单机磁盘连接数全到顶。分库分表是最后手段,先归档争取喘息。几周做完:垂直拆 vs 水平拆、选分片键 buyer_id+订单号基因法、hash 取模一次给足分片数、攻克分布式 ID 与跨片分页、双写灰度迁移全程对账。- 0
- 0
-
分布式事务踩坑:服务拆分后订单成功库存却没扣的复盘
服务拆分后订单、库存、积分各自独立数据库,对账发现一批订单创建成功了但库存没扣。根因是 @Transactional 只管本地单库,跨服务操作毫无事务保障。两周治理:认清本地事务边界、本地消息表、RocketMQ 事务消息、TCC 强一致、Seata AT 低侵入,以及方案选型与对账兜底。- 0
- 0
-
接口幂等设计实战:从一次重复扣款事故说起
支付系统出过一次后背发凉的事故:用户被同一笔订单扣了两次款。根因是前端网络抖动时重试了提交请求,而下单接口压根没做幂等。一周治理:理清哪些写接口必须幂等、补数据库唯一索引兜底、幂等号前置查重、token 机制防表单重复提交、状态机幂等。同一请求并发重放 200 次只落 1 笔订单。- 0
- 0
-
雪花算法时钟回拨导致 ID 重复:一次凌晨主键冲突的复盘
订单系统用雪花算法生成订单号,某天凌晨数据库报主键冲突:两笔订单拿到同一个 ID。根因是 NTP 同步把一台机器时钟往回拨了 340ms,雪花算法最怕时钟回拨。几天治理:补时钟回拨防御(小回拨等待、大回拨拒绝)、用只增不减的逻辑时间兜底、workerId 改自动分配、NTP 改 slew 平滑校时。之后再没出现 ID 重复。- 5
- 0
架构设计
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×