从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 第一本很适合开栏：《金钱心理学》（The Psychology of Money），摩根·豪泽尔。 它的核心
滚动发布时，监控里出现了 0.3% 的 5xx 毛刺 4 月一次常规滚动更新，发布过程中 Grafana 的 5xx 曲线冒出一排小毛刺，单个实例发布期间大约丢了 0.3% 的请求。量不大，但每次发布都有，说明是上下线姿势不对，不是偶发。 我们的 Java 服务跑在 K8s 上，Spring Boo
一次发布把下单接口打挂了，CI 里却全是绿的 4 月一次常规发布后，下单接口 5xx 飙到 12%。回看 CI 流水线，单元测试全绿。问题出在：单元测试只覆盖了方法内部逻辑，没人验证"接口契约"本身——前端传的字段名改了，后端字段名也跟着改，但两边没对齐，网关层反序列化直接失败。 这事之后我把接口自
升级 Redis 7.0 时，我把一段 Lua 脚本换成了 Functions 4 月 Redis 7.0 正式发布，我们把集群从 6.2 升到 7.0。升级本身平滑（RDB/AOF 兼容），但翻 release notes 时发现一个我一直想要的东西：Redis Functions。我们原本用 L
集群重启后要 40 分钟才能变绿，问题出在分片数 我们用 ES 做商品搜索和日志检索，版本从 7.15 升到 8.0（2022 年 2 月发布，正式用上）。3 月一次故障演练，重启集群后主分片恢复花了 40 分钟才变绿，期间搜索不可用。排查下来，根因是分片数设错了：一个 200 GB 的索引被切成
大促压测：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
4.2 G 的 hprof，MAT 自己先 OOM 了 12 月 22 号，营销服务的一个 Pod 因为 java.lang.OutOfMemoryError: Java heap space 挂了。运维在容器被重启前抓到了堆转储，文件大小 4.2 G。我把文件 scp 到本地，双击打开 MAT，进
