从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 第一本很适合开栏：《金钱心理学》（The Psychology of Money），摩根·豪泽尔。 它的核心
第一次把单体拆出 Dubbo 服务，踩了五个坑 11 月，组里决定把用户中心从订单系统里拆出来，做成独立的 Dubbo 服务。这是我第一次真正搭分布式服务，之前只在本地 demo 里跑过。 技术选型是 Dubbo 2.7.3 + Zookeeper 3.4.14 + Spring Boot 2.1.
商品详情页 800 毫秒，我把它改成了 180 毫秒 10 月底做性能优化，商品详情页是重点。这个页面要聚合 6 个数据源，原来的代码是串行调的： public ProductDetailVO getDetail(Long skuId) { ProductVO product = produ
一个用户被扣了两笔钱：关于幂等我踩过的坑 10 月 12 号下午，客服转来投诉：用户买了一双 899 的鞋，银行卡扣了两次款，订单表里却只有一条订单。 查下来是这样的：用户点"立即支付"时网络抖了一下，前端没收到响应，自动重试了一次。两次请求都打到了支付回调接口，回调里没有做幂等，于是扣款发生了两次
对账少了 3.7 万元：一行 parallelStream 惹的祸 10 月 8 号，财务来找我，说 9 月 30 号的日报表金额对不上，系统算出来 148.2 万，实际银行流水 151.9 万，少了 3.7 万。而且奇怪的是，同一个任务重跑一遍，出来的数字还不一样：第二次是 149.6 万。 同样
Code Review 时发现同事用 CyclicBarrier 写了个一次性等待 9 月中的一次 code review，我看到同事写了这么一段：一个接口要并行查三个数据源然后汇总，他用 CyclicBarrier 做同步。功能是对的，但读起来很别扭——CyclicBarrier 那套 await
读 ThreadPoolExecutor 源码时，我顺手压测了三种队列 9 月份啃线程池源码，看到构造函数里那个 BlockingQueue<Runnable> workQueue 参数，我才意识到自己从来没认真选过它——一直是 Executors.newFixedThreadPool(20) 一路
我给一个祖传方法补单测，改到怀疑人生 9 月初，师兄让我给订单模块的几个核心方法补单元测试，说是要接入 SonarQube 看覆盖率。我挑了个"看起来最简单"的方法开工，然后就掉坑里了。 方法长这样： @Service public class OrderService { public
上线时那个 NoSuchMethodError：两个 jar 里有同一个类 8 月底发版，新功能上线后立刻报了一堆错： 2019-08-27 20:14:32.881 ERROR [http-nio-8080-exec-3] c.x.web.ExceptionHandler - Handler
同事问我：为什么加个依赖就能用了 8 月中旬，刚入职的同事跑来问我一个他觉得"很魔幻"的事：他只在 pom 里加了 spring-boot-starter-data-redis，然后 @Autowired private StringRedisTemplate 就能用了，中间没写任何配置类。他问我
MAT 里那个 12 万的 java.lang.ref.Finalizer 8 月初排查一个服务的老年代增长，dump 下来用 MAT 打开，Dominator Tree 里第三名是 java.lang.ref.Finalizer，12.4 万个实例，占了 210 MB。我当时看不懂这是个什么类，点
故障演练那天，我们丢了 400 多条缓存 key 公司 7 月底做了一次故障演练，运维在预发环境把 Redis 主节点的进程 kill 掉，看哨兵能不能自动切换。切是切成功了，但演练结束后比对数据，主库的 key 数量是 12,480,331，切过去之后新主库只有 12,479,905，少了 426
慢查询日志里那条 1.8 秒的 SQL 7 月底，DBA 每周发的慢查询报表里，我们订单库有条 SQL 排第一：执行 14.7 万次，平均 1.83 秒，扫描行数 28 万。SQL 长这样： SELECT order_no, user_id, amount, status, create_time
批量扣款任务卡死后，单笔扣款接口也全挂了 7 月 5 号早上 9 点 12 分，监控开始告警：/api/deduct 接口响应时间从 60 毫秒飙到 30 秒全部超时。同时 DBA 在群里说，account 表上有锁等待，已经持续 4 分钟。 第一反应是数据库慢查询。但登上机器看，应用这边 CPU
查一个用户的投诉，我翻了两小时日志 上个月客服转来一个工单：用户说 6 月 20 号下午下过一单，付了钱但订单状态还是"待支付"。我拿着用户 ID 去 ELK 查，搜出来 3800 多条日志，全是这个用户的，而且几个接口的日志混在一起，根本分不清哪几条是同一次请求的。 翻了两个多小时才拼凑出大概的调
运维在群里 @ 我：你们这个服务内存一直在涨 那天下午运维丢了一张图到群里，是 Zabbix 上我们订单服务的 JVM 内存曲线，从早上 9 点的 1.2 GB 一路爬到下午 4 点的 3.8 GB，容器限制是 4 GB。他问：这是不是内存泄漏？ 我当时的第一反应是想 dump 下来看，被带我的师兄
