压测雪崩复盘:每一层的超时都设成了 30 秒 5 月初做 618 前的压测。我们给网关发了 3000 QPS 的流量,持续 90 秒,结果整个交易链路崩了:网关大量 504,订单服务 CPU 98%,成功率从 99.9% 掉到 34%,压测停止后还花了 4 分钟才恢复。 排查时发现一个很荒谬的事:从
一个用户被扣了两笔钱:关于幂等我踩过的坑 10 月 12 号下午,客服转来投诉:用户买了一双 899 的鞋,银行卡扣了两次款,订单表里却只有一条订单。 查下来是这样的:用户点"立即支付"时网络抖了一下,前端没收到响应,自动重试了一次。两次请求都打到了支付回调接口,回调里没有做幂等,于是扣款发生了两次
短信服务商挂了 23 分钟,我们丢了 1247 单 那是去年 11 月的事。我们合作的短信服务商机房故障,接口全部超时。按理说短信发不出去不是什么大事,但那天下单成功率从 99.9% 掉到了 63%,23 分钟里少成交了 1247 单。 原因很简单:下单接口里同步调用了发短信,短信服务超时 30 秒
DBA 丢给我一张容量曲线图 2 月底,DBA 在周会上放了张图:订单主库 t_order 已经 4200 万行,数据文件 38G,加上索引一共 51G,按每月 380 万行的增速,年底到 8000 万行,明年年中破亿。他的结论是"该考虑分库分表了"。 主管把这个评估任务派给了我。说实话我当时有点虚
接手了一个 4000 行的 Service 类 三月底,组里那个做了两年的老项目交到我手上。第一次打开 OrderServiceImpl.java,IDEA 右下角显示 4127 lines,我愣了一会儿。往下翻,一个方法从 1032 行开始,到 1450 行结束,中间嵌套了 7 层 if。 更绝望