从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 这个栏目不打算做成读书笔记的搬运。我做了八年 Java 和 AI，又自己跑过出海盘子、也清零过两次，读这些书
现象：堆才用了一半，容器就被 OOMKilled 10 月 28 号晚上，网关服务的一个 Pod 被 K8s 杀了。 $ kubectl describe pod api-gateway-5f8b7c9d4-xt2n9 Last State: Terminated Reason:
现象：翻到第 1000 页要 8 秒 运营反馈"订单列表翻页越往后越慢"。我们复现了一下，第一页 23 ms，第 100 页 340 ms，第 1000 页 8.2 秒。 SQL 长这样（每页 20 条）： SELECT * FROM t_order WHERE user_id = 100372
安全组的一封邮件 2021 年 1 月 20 号上午，公司安全组群发了一封邮件，标题是《关于 fastjson 反序列化漏洞的紧急排查通知》，要求各业务线在周五前上报使用了 fastjson 的服务清单和版本。 我心里咯噔一下。我们三个核心服务全在用 fastjson，版本 1.2.62。 $ mv
现象：每次发版，消费停 47 秒 9 月底做容量复盘时，我发现一个奇怪的规律：每次发布，Kafka 消费 lag 都会先涨后落，中间有大约 45 到 60 秒消费完全停住。看消费者日志，那段时间全是这个： 2021-09-28 14:22:31.407 WARN [Consumer client
告警：Pod CPU 987% 10 月 8 号下午，告警： [P1] order-service CPU 使用率 987% (limit 800%) 持续 20 分钟 CPU 是 8 核 limit，987% 意味着快跑满了。接口 P99 从 120 ms 涨到 3.4 秒，部分请求超时。 这类
目标：大促前把商品详情接口压到 8000 QPS 9 月 20 号拿到大促的容量需求：商品详情接口要扛 8000 QPS，P99 控制在 300 ms 以内。第一次压测跑下来只有 2000 QPS，P99 1.2 秒，差了 4 倍。 前后两周五轮优化，最后压到 8200 QPS、P99 178 ms
背景：一个新服务要不要上 WebFlux 9 月中旬要起一个新服务，作用是"详情页聚合"：前端调一次接口，我们并行调商品、库存、价格、营销、评价五个下游，聚合后返回。组里有人提议用 WebFlux，理由是"调用多、IO 密集，响应式最合适"。 我当时持保留态度，就花了一周做了个 POC，两边都实现一
为什么又搞了一套 Prometheus 我们本来有 SkyWalking 8.6，链路追踪和拓扑都挺好用。但它有两个地方不满足需求：一是数据默认只存 7 天（ES 成本摆在那），二是加自定义业务指标比较麻烦，我更习惯"自己埋点 + 自己配告警"这套。 于是给核心的几个服务加了 Prometheus
起因：压测时前 3 分钟的数据全不能看 9 月初给一个轨迹计算服务做压测，用 JMeter 压 10 分钟，发现吞吐曲线很怪：第 1 分钟 3200 QPS，第 3 分钟 7100 QPS，之后稳定在 8900 QPS 左右。同样的机器、同样的并发，吞吐差了 2.8 倍。 这其实就是 JIT 预热的
告警：0 点 15 分，堆积 1200 万 8 月 31 号晚上大促，我们值守到凌晨。0 点 15 分，告警响了： [P1] RocketMQ consumer lag: group=order-sync-consumer, topic=ORDER_SYNC_TOPIC diff=1,20
起因：财务对账时发现的几十笔差异 8 月初，财务同事甩过来一张表：7 月份有 63 笔订单，用户积分扣了但优惠券没发。我们日均 12 万单，63 笔占比万分之五，但财务按笔核对，一笔都不能有。 查下来问题出在下单流程。下单成功后要发一条消息给营销服务，让它发优惠券： @Transactional p
需求：30 分钟未支付自动关单 产品提了个很常见的需求：用户下单后 30 分钟没支付，自动关闭订单并释放库存。我们日均订单 12 万，粗略统计落在 30 分钟窗口内未支付的约 3.4 万单。 这个需求本质是"延迟任务"，实现方式有好几种，我基本都试过，把各自的坑记一下。 方案一：定时扫表 最朴素的写
现象：优惠券服务挂了，我们的订单服务跟着挂了 7 月 28 号晚上 8 点多，告警炸了。不是优惠券服务告警，是订单服务告警：Tomcat 线程池打满、健康探针失败、K8s 开始杀 Pod。 [P1] order-service / http_server_requests_seconds P99 >
同事的问题：我加了 @Cacheable，为什么没生效 上周三下午，组里的小杨问我："我在方法上加了 @Cacheable，压了 100 次，数据库慢查询日志里还是 100 条，Redis 里也看不到 key，是不是缓存没配好？" 我过去看了一眼他的代码： @Service public class
现象：一个接口慢，但监控上看不出慢在哪 客服反馈"订单详情页打开要转好几秒"，我们查 Grafana，GET /order/{id}/detail 的 P99 从平时的 120 ms 涨到了 900 ms 左右，P50 没变。也就是说不是全量慢，是部分订单慢。 SkyWalking 8.6 上只能看
