语义缓存上线一个月，命中率 8.3% 三月份我们给客服 Agent 上了语义缓存，预期是「相似问题不用重复问模型，能省一大笔钱」。上线一个月看数据，命中率 8.3%，省下的钱还不够维护缓存本身的成本。 这篇文章记录我们怎么把命中率从 8.3% 提到 41%，以及中途推翻重做的一版设计。 先看为什么这
压测卡在 400 QPS 上不去 知识库问答系统三月中旬做上线前压测，目标 800 QPS，结果压到 400 就开始大量超时。看 Grafana 面板，网关 CPU 才 40%，数据库连接池很闲，但整体 P99 已经飙到 3.2s。 拿 async-profiler 抓了 60 秒火焰图，TIME_
客服机器人上线两周，P95 首字延迟 4.2 秒 9 月初，我们给内部工单系统做的智能客服上了线。第三天开始收到投诉："问一句话要等四五秒才出字"。我拉了 Grafana 看，数据比投诉描述的还难看： gateway_request_duration_seconds{quantile="0.95",
缓存和数据库又双叒不一致了 我们的商品详情页用"先更新 DB，再删缓存"的策略。大多数时候没问题，但运营一次批量改价后，部分用户看到的价格还是旧的，持续了十几分钟。根因是并发下的时序问题：线程 A 更新 DB、还没删缓存时，线程 B 读了旧 DB 值并写回缓存，导致 A 的删除"删了个寂寞"，脏数据
大促压测：Redis 被打到 12 万 QPS，还是扛不住 3 月大促前做全链路压测，商品详情页的接口目标 5 万 QPS。单 Redis 集群（3 主 3 从，Redis 6.2）在 12 万 QPS 时 CPU 跑满，P99 从 3 ms 飙到 47 ms，再往上就开始超时。加节点成本太高，而且
压测报告里那行 P99 把我叫住了 11 月中旬做双十一前的容量压测，商品详情接口 3000 QPS 下 P99 是 42 ms，还算好看。压到 6000 QPS 的时候 P99 直接跳到 180 ms，而且曲线是锯齿状往上爬，不是平稳的。同时 Redis 集群 CPU 到了 61%，带宽 780
同事的问题：我加了 @Cacheable，为什么没生效 上周三下午，组里的小杨问我："我在方法上加了 @Cacheable，压了 100 次，数据库慢查询日志里还是 100 条，Redis 里也看不到 key，是不是缓存没配好？" 我过去看了一眼他的代码： @Service public class
code review 时，我们为一个顺序吵了半小时 一月中旬，同事小王提了个 PR，商品改价接口里他这么写的： @Transactional public void updatePrice(Long skuId, BigDecimal newPrice) { redisTemplate.d
六月十三号上午，MySQL 被 3 万 QPS 打挂了 那天早上 9:07，我还在地铁上，DBA 的电话就打过来了："你们的库 CPU 100%，连接数打满，赶紧看看是不是缓存挂了。" 到公司一看监控，数据库 QPS 从平时的 800 飙到 31000，CPU 100%，连接数 500 打满，大量请
运营说：我明明改了数据，页面还是旧的 去年做后台管理系统时遇到件怪事。运营在页面上改了一条商品记录的库存，保存成功，数据库里确认已经改了，但刷新列表看到的还是旧值。过几分钟再刷又对了。 我把日志级别调到 DEBUG，看到这么一段： ==> Preparing: SELECT id, name, s
