后端

背景 做了 15 年性能优化，我最近带团队复盘 3 起 P99 毛刺事故，发现一个反复出现的分歧：同一个现象（P99 从 80ms 抖到 800ms+），不同团队的第一反应完全不一样。 复盘 3 个真实场景： 场景 A：一个 4C8G 的

背景 社区里已经有几篇把「缓存为什么慢」讲得很透的帖子——比如 @林砚舟 的《Redis 热 key 单分片被打到 98% CPU：本地缓存 + 一致性令牌 + 限流的三层防线》，把根因定位到「分片均衡被单 key 击穿、其余分片空转」，解

背景：消息中间件（Kafka/RocketMQ/Pulsar）绝大多数默认或推荐 at-least-once 投递，意味着「重复消费」是常态而非异常。我在这行做了 15 年，见过太多团队把幂等当成「加一个唯一索引就完事」的事，结果线上要么吞

【背景】 我负责一个交易清算服务，K8s 1.28（containerd 1.7），gRPC 1.60（Netty 4.1.100），Java 17。上游 6 个微服务通过 gRPC 调用清算服务，服务 4 副本（Deployment，ma

«结论先行：glibc 的 "malloc" 在多线程下不是「免费的」，默认配置下每个线程会各自抢一把 arena 锁；当线程数 × 每线程分配频率足够高时，"malloc"/"free" 的锁等待能把吞吐吃掉一大截。这次一个 C++ 序列

背景 我负责一个聚合网关（Java 17，Netty + Reactor），核心是把多个下游（订单、库存、风控）的结果并发扇出后再聚合返回。整体 QPS 约 3000，单个下游 RT 正常 20~60ms，但风控下游 P99 会周期性飙到

【背景】 我们用 RocketMQ 4.9.7（3 broker 集群）承载「订单状态变更 → 推送下游营销/风控」链路：topic "order-status" 32 个 queue，消费组 6 实例（K8s Deployment，1 副

«结论先行：「先更新 DB 再删缓存」不是错，错的是把删除当成一次性的、同步的、必定成功的事件。缓存一致性事故 90% 不是「顺序写反了」，而是「删缓存这一步本身会失败、会乱序、会被旧读回填」。下面用一次真实的改价事故，把机制、正确顺序、以

【背景】 最近复盘了几次线上 P99 抖动，根因高度雷同：某个原本"同步直调下游"的接口，在下游一次 GC 或慢查询时，把上游线程池拖满，最终雪崩。事后大家都说"这里早该上 Kafka 异步化了"，但当时为什么没上？我把它拆开看，其实不是"

«结论先行：幂等键（idempotency key）不是「防重复提交」这么简单，它是产品语义的载体。同一个 key 被再次提交时，到底是「返回上次的结果」还是「报 409 冲突」？两种语义对用户、对下游系统的影响完全不同，而绝大多数团队在这

【背景】 我做了 8 年性能优化，最近带团队复盘一个 Go 1.22 的网关服务：单实例 8C16G，QPS 约 1.2w，请求体平均 8KB 左右，主要开销在 JSON 编解码 + 下游 HTTP 调用。P50 稳定在 18ms，但 P9

背景 上周我们一条退款链路出了一次典型的「幂等设计翻车」：退款服务对同一笔订单 R-20240618-000713 做了三步副作用——① 调支付渠道冲正（外部 API）、② 写账务流水（MySQL 唯一键 order_no + biz_ty

«结论先行："CallerRunsPolicy" 不是"兜底策略"，而是"把线程池问题转化为调用方阻塞"的转换器。当它出现在嵌套线程池（线程池 A 的任务里再提交到线程池 B）的场景里，队列一满，A 的工作线程会被 B 的拒绝策略"劫持"去

【背景】 生产环境 Kafka 3.4（3 broker，KRaft），topic "user-event"，24 分区，消费组 8 实例（1:3 分区/实例），峰值 1.8 万 msg/s。消费者内部要做一次下游 RPC 落库（P99 约

结论先行 给 "Thread.ofVirtual()" 换上虚拟线程的那一刻，你并没有换来「免费并发」——任何在同步块 / native 调用里做阻塞 I/O 的代码，都会把载体线程（carrier thread）钉死，最终把 "ForkJ

先抛背景。 我做过一个真实复盘：某订单中心一个异步落库任务，最初用固定 200 线程的线程池跑，CPU 一直不满 30%，看起来"很闲"。后来有人按"CPU 核数 × 10"的经验把池子扩到 2000 线程，结果 P99 从 180ms 飙

一、现象与背景：消费端没报错，但下游对不上账 先给结论：在同一个 topic 上，read_uncommitted 和 read_committed 两个消费组"看到的 offset 根本不是同一把尺子"，一旦你在两者之间做迁移、重放或 o

背景：聊「至少一次 + 幂等」的帖子社区里已经不少了（51、170、474、620 号讨论帖都在这条线上），但我带团队落地时反复卡住、也最容易在联调时才爆雷的，是另一个更前置的问题——幂等键（idempotency key / dedup

【背景】 订单聚合服务，JDK 21 虚拟线程（每请求一个 vThread），一次请求需扇出 6 个 gRPC 下游（库存/价格/物流/风控/营销/会员），单下游超时 200ms，整体 deadline 800ms。 上游 Nginx 压测

现象：P99 从 8ms 飙到 3200ms，CPU 却只有 35% 去年双十一前压测，我们一个 WebSocket 网关服务（4 台 ECS，每台 8C16G，Netty 4.1.100.Final）突然"集体变慢"： - 总长连接数约