从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 第一本很适合开栏：《金钱心理学》（The Psychology of Money），摩根·豪泽尔。 它的核心
上线第二天：生成了两个一样的订单号 十二月十号，我们把自增主键换成了 Snowflake 生成分布式 ID。上线第二天，测试同学在日志里发现了重复： 2020-12-11 10:22:31.114 WARN IdGenerator - 检测到时钟回拨, workerId=3, lastTimest
运营说：这个报表等到花儿都谢了 十一月底，运营同学提了个工单："销售明细报表要等 8 秒以上，导出的时候更是直接超时。" 我看了下 slow log，那条查询平均 8.4 秒，最慢的一次 21 秒： # Time: 2020-11-24T14:22:31.882113+08:00 # User@Ho
十一月二十三号：一条 SQL 拖垮了五个服务 那天上午 10:07，监控大屏开始变红。从商品服务开始，10 分钟内波及五个服务，最后整个交易链路不可用，持续 23 分钟。这篇把整个过程复盘一遍，包括我们当时做错的判断。 时间线 时间 事件 10:07 商品服务接口 TP99 从 45ms 涨到 3.
压测数据：同样的计数，快了 6 倍 十一月中旬做网关的埋点统计改造，需要统计每个接口的调用次数和总耗时。我一开始用的 AtomicLong： private final Map<String, AtomicLong> counters = new ConcurrentHashMap<>(); pu
刚上读写分离，客服就收到投诉了 十一月初，我们把订单库做了读写分离：一主两从，写走主库，查走从库。用 ShardingSphere-JDBC 5.0.0-alpha（当时叫 Sharding-JDBC），配置很简单： spring: shardingsphere: datasource:
十月的一个早晨：Full GC 每小时 40 次 十月二十六号一早，监控群里机器人在刷告警。报表服务的 Full GC 频率从平时的每小时 0~1 次，涨到了 40 次。 $ jstat -gcutil 1 2000 10 S0 S1 E O M CC
十月十六号：一个线程池配置引发的连锁故障 那天下午三点，监控系统开始报"下单接口超时率 35%"。我打开看的时候，发现不只是下单——商品详情、购物车、用户信息，几乎所有接口都在超时。网关的活跃连接数从平时的 200 涨到了 7800。 整个服务集群像是被什么东西卡住了。 现象：线程全在 WAITIN
起因：前后端又为接口字段吵起来了 九月末的一次需求联调，前端同学找我："你这个接口的 amount 字段到底是字符串还是数字？我这边拿到的有时候是 "19.90"，有时候是 19.9。" 查了一下，是 BigDecimal 序列化的问题，有些地方用了 @JsonSerialize(ToStringS
问题：一个只在生产出现的接口变慢 九月下旬，客服反馈"订单详情页打开很慢"。我在测试环境怎么点都是 80ms，生产上就是 3 秒左右。 按以前的办法，要么加日志重新发版（生产发一次要走流程，至少半小时），要么 jstack 抓线程栈（只能看某一瞬间的状态，看不到耗时分布）。这次我试了下 Arthas
凌晨三点的抖动：Redis 响应时间突然飙到 800ms 九月九号大促那天晚上我值班，凌晨三点被叫起来。监控大屏上 Redis 的 P99 响应时间从平时的 0.4ms 冲到 812ms，持续了大概 40 秒，然后自己恢复了。 应用侧的连锁反应更难看：商品详情页接口 TP99 从 45ms 涨到 3
一个批量接口慢在哪：不是 Redis 慢，是网络慢 八月下旬优化一个批量查询接口。它要一次读 200 个商品的库存，我一开始的写法很直白： public Map<String, Integer> batchGetStock(List<String> skuIds) { Map<String,
大促前的准备：缓存预热到底该怎么做 八月中旬，运营定在 9 月 9 号做一场大促。我被分到的任务是"保证缓存不崩"，具体要回答两个问题：活动开始时缓存是空的怎么办？某个商品突然爆了怎么办？ 我们的缓存现状：Redis 6.0，一主两从 + 哨兵，单机 12GB。商品详情页的缓存是「被动」的——用户访
告警：Deadlock found when trying to get lock 八月中旬的一个晚上，钉钉群开始刷告警。库存服务的日志里出现了这个： 2020-08-13 21:14:32.881 ERROR [http-nio-8080-exec-42] o.s.i.d.i.InventoryM
报错：Result window is too large 运营后台有个"导出全部商品"的功能，前端做成了分页拉取，一页 100 条，用循环一直翻到最后一页。上线当天就炸了，日志里全是这个： org.elasticsearch.ElasticsearchStatusException: Elasti
接手搜索需求：MySQL like 已经撑不住了 七月份产品提了个需求：商品搜索要支持关键词模糊匹配、按分类筛选、按价格排序、还要高亮。我们当时是这么查的： SELECT * FROM t_item WHERE title LIKE CONCAT('%', #{keyword}, '%') AN
