目标：大促前把商品详情接口压到 8000 QPS 9 月 20 号拿到大促的容量需求：商品详情接口要扛 8000 QPS，P99 控制在 300 ms 以内。第一次压测跑下来只有 2000 QPS，P99 1.2 秒，差了 4 倍。 前后两周五轮优化，最后压到 8200 QPS、P99 178 ms
商家后台一个接口 2.3 秒，被投诉了半年 3 月上旬，客服转过来一条工单：某连锁商家反馈"经营概览"页面打开要转好几秒，用了半年一直这样。 我复现了一下，确实慢。这个接口返回商家今日/本月/累计的订单量、销售额、退款率、热销商品 Top5、会员增长数，一共 9 个指标。 第一步永远是耗时拆解，不是
review 时和同事吵了一架 1 月中旬做 code review，我写了一段统计订单金额的代码： long total = orders.stream() .mapToLong(Order::getAmount) .sum(); 同事评论："Stream 有性能
一个批量接口慢在哪：不是 Redis 慢，是网络慢 八月下旬优化一个批量查询接口。它要一次读 200 个商品的库存，我一开始的写法很直白： public Map<String, Integer> batchGetStock(List<String> skuIds) { Map<String,
1.2 亿条订单导入 ES，按当时的速度要跑 66 小时 二月初接了个活：把 MySQL 里 2017 年之后的历史订单同步到 Elasticsearch，给客服系统做多条件检索。总共 1.24 亿条。 我先用原来的同步代码跑了半小时，用 _cat/indices 数了一下文档数增长：单机 470
一个订单对象序列化 100 万次，花了 4.2 秒 十月份做对账文件的导出，要把 100 万条订单转成 JSON 写到文件里。我用 Fastjson 1.2.49，代码就一行： String json = JSON.toJSONString(order); 跑完计时：4.2 秒。我当时觉得挺快了，
导出功能上线，CPU 直接干到 780% 新做的对账单导出上线第一天，监控图上 CPU 从 15% 一条直线拉到 780%（8 核机器）。同一个时间点 Full GC 频率从每小时 2 次变成每分钟 30 多次。导出的文件也就 4MB 大小，不至于。 我用 jstack 抓了几把线程，大量线程停在这
