大促压测：Redis 被打到 12 万 QPS，还是扛不住 3 月大促前做全链路压测，商品详情页的接口目标 5 万 QPS。单 Redis 集群（3 主 3 从，Redis 6.2）在 12 万 QPS 时 CPU 跑满，P99 从 3 ms 飙到 47 ms，再往上就开始超时。加节点成本太高，而且
重构支付模块时，我把 600 行 if-else 拆成了四个模式 上个月接手支付模块重构。打开 PaymentService.pay() 那一刻我有点懵：一个方法 600 多行，开头十几个 if (channel == WECHAT) ... else if (channel == ALIPAY)
对账群里跳出一条消息：同一笔订单扣了两次款 2 月 19 号下午，财务在对账时发现一笔订单出现了两次支付成功记录，金额都是 199 元。看起来是消费者把消息重复处理了。 我们用的 Kafka 是 3.1.0，消费者是 enable.auto.commit=true 默认配置。同事问我：不是说 Kaf
架构评审会上，两个人对着吵了四十分钟 2 月中旬的一次架构评审，议题是"下单链路要不要上 Seata"。后端 A 主张用 AT 模式，理由是几乎不用改业务代码；后端 B 坚持用消息队列做最终一致，理由是"我们承受不了 Seata 挂掉导致下单全挂"。 我最后拍板：全都不用，主链路走本地消息表，退款单
「Arthas 凭什么不用改代码就能看到方法耗时」 2 月初排查一个慢接口，我用 Arthas 的 trace 打出了每一层调用的耗时。旁边一个刚工作两年的同事看完很惊讶：我们没加任何埋点，也没改代码，它怎么知道每个方法花了多久？ 这个问题一两句话讲不清楚，正好我那几天在给公司内部的压测平台做一个无
「下单偶尔失败，刷新一下就好了」 1 月中旬，运营那边反馈：商家后台点"确认收货"有时候会失败，弹一个系统繁忙，再点一次就好了。我们查日志，一天里有 200 多条这样的错： com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException:
「为什么这个 DTO 里的字段改不动了」 1 月底，一个新同事在群里问：他给订单查询的返回 DTO 加了个 @Data，然后用 Jackson 反序列化的时候报了一堆奇怪的错，改成 record 之后就好了，问我能不能把所有 DTO 都换成 record。 我当时的回答是：DTO 可以用，但不是所有
「线程数加到 800 了，还是上不去」 1 月中旬看压测报告，开放平台那个网关服务的并发一直卡在 4000 左右。压测的同学在群里说：「Tomcat 线程数已经从 200 加到 800 了，加不动了，再加 Full GC 就开始频繁。」 这个症状太典型了——线程成了并发的天花板。我把之前攒的 Loo
重构一段 140 行的 if-else 链 1 月初接手支付网关的回调处理模块，打开 NotifyDispatcher 一看，是一个 140 行的 if-else 链。我们新服务用的是 JDK 17（ZGC + G1 都在测），正好可以试试新的语法。 原始代码长这样 public NotifyRes
发现：21 点 47 分，Pod 开始被 OOMKilled 2021 年 12 月 28 号晚上，年终大促的预热场。21:47 分监控群开始报： [P1] promotion-service 实例不可用 事件类型：ContainerOOMKilled 命名空间：prod Pod：pro
