背景：大促前的压测暴露了长尾 八月底大促压测，核心的下单查询接口平均 RT 只有 120ms，看着挺好，但 P99 飙到 800ms，监控里偶发还有 1.5 秒的尖刺。平均好看掩盖了长尾，而用户体验恰恰被那 1% 的慢请求毁掉。我接了这活，目标是把 P99 压到 150ms 以内。 全链路耗时分析：
复盘：一次被迫停更的迭代 四月那次版本上线前夜，我盯着依赖图发呆——一个订单核心模块被 27 个地方引用，改一处要回归 40 个用例，测试同学直接摆烂说「这版先别动它」。这不是第一个被技术债拖住的需求。入行第六年，我越来越觉得，技术债不是写烂代码，是「明知该改但一直没改」的累积。 债务识别：先把账算
一次没顶住的流量 去年大促，预估峰值 8000 QPS，实际来了 1.4 万，订单服务被打挂 12 分钟。复盘发现：我们的容量评估靠的是"去年×2"的拍脑袋，没有真实压测支撑，对系统的真实拐点一无所知。那天凌晨告警炸了，扩容来不及，限流没配，全靠手动重启扛，资损不小。这次我把容量评估正经做了一遍，把
那个 3000 行的 Service 接手交易核心模块时，OrderService.java 有 3128 行，下了 47 个 @Autowired 的 DAO 和远程 client。任何一处改动我都得屏住呼吸。上周一个改下单幂等的小需求，回归测试就跑了三轮，改动 8 行、提心吊胆一整天。更糟的是，
订单系统重构：一个"订单"对象膨胀到了 3000 行 我们老订单系统里有个 Order 类，承载了下单、改地址、退款、发票、物流查询……所有逻辑，文件 3000 多行，改一处怕动全身。重构时我用 DDD 的聚合（Aggregate）思想重新切分，核心问题其实就一个：聚合边界划在哪。划错了，要么事务跨
面试官问：100 万人抢 1000 件商品怎么设计 前阵子做架构分享，被同事用一道经典题考住："100 万并发抢 1000 件商品，怎么保证不超卖、系统还不挂？"这题看着老，但真要落地，每一层都有坑。我把我们实际做过的秒杀系统的设计要点拆开讲——不是教科书，是踩过坑的版本。 要点一：库存扣减，必须原
对账发现：账户余额和流水对不上 3 分钱 做交易系统最怕"状态对不上"。我们有个积分账户服务，某天对账脚本报：用户 A 的余额是 1200，但流水累加只有 1199.97。差 3 分钱，谁也说不清是哪笔操作漏了。传统的"改余额 + 插流水"两条写，因为中途异常出现过不一致。痛定思痛，我把核心域改成了
一次资损：限领 1 张的券，用户领了 2 张 1 月初的一个上午，运营在群里 @ 我：一张"新客专享 50 元券"，配置的是每人限领 1 张，有用户领到了 2 张，已经核销了一张。 我查了数据库： mysql> SELECT user_id, coupon_id, count(*) c FROM c
重构支付模块时，我把 600 行 if-else 拆成了四个模式 上个月接手支付模块重构。打开 PaymentService.pay() 那一刻我有点懵：一个方法 600 多行，开头十几个 if (channel == WECHAT) ... else if (channel == ALIPAY)
发现：21 点 47 分，Pod 开始被 OOMKilled 2021 年 12 月 28 号晚上，年终大促的预热场。21:47 分监控群开始报： [P1] promotion-service 实例不可用 事件类型：ContainerOOMKilled 命名空间：prod Pod：pro
