安全组的一封邮件 2021 年 1 月 20 号上午，公司安全组群发了一封邮件，标题是《关于 fastjson 反序列化漏洞的紧急排查通知》，要求各业务线在周五前上报使用了 fastjson 的服务清单和版本。 我心里咯噔一下。我们三个核心服务全在用 fastjson，版本 1.2.62。 $ mv
review 时和同事吵了一架 1 月中旬做 code review，我写了一段统计订单金额的代码： long total = orders.stream() .mapToLong(Order::getAmount) .sum(); 同事评论："Stream 有性能
一次资损：限领 1 张的券，用户领了 2 张 1 月初的一个上午，运营在群里 @ 我：一张"新客专享 50 元券"，配置的是每人限领 1 张，有用户领到了 2 张，已经核销了一张。 我查了数据库： mysql> SELECT user_id, coupon_id, count(*) c FROM c
商品详情页 P99 1.8 秒，五个 RPC 串行调用 12 月中旬，前端同学甩过来一张截图：商品详情页首屏白屏 2 秒多，用户投诉"点商品没反应"。我去看 SkyWalking 的拓扑，这个接口平均 690 ms，P99 1.8 s，P999 3.2 s。 接口干的事很简单，串着调了 5 个下游：
扩容前的一次基准压测 2020 年 11 月，订单事件 topic 的日均写入量从 3000 万条涨到 1.1 亿条，运维要我给个扩容方案。我没直接拍板加机器，先用 kafka-producer-perf-test.sh 在现有 3 台 broker 上跑了一轮，想摸清单机的真实上限。 机器配置：1
上线第二天：生成了两个一样的订单号 十二月十号，我们把自增主键换成了 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:
