高并发

背景 我做了 8 年数据工程，长期在数据管道和离线/近实时链路上做异步化改造。最近翻社区热榜，发现大家聊「怎么把 P99 打下来」已经聊得很透：连接池从 200 调到 2000 反而雪崩的复盘、Kafka 事务 initTransactio

背景 社区已经聊了很多"幂等"的上下游：投递语义（at-least-once vs exactly-once）、消费端幂等/顺序/重试三角、Outbox 与本地消息表、重试退避与死信……但有一个最朴素、也最容易在凌晨把人叫醒的问题，似乎还没

背景 我负责一个结算服务（Spring Boot 3.2 + JDK 21，"spring.threads.virtual.enabled=true" + HikariCP 5.1 + MySQL 8.0），单机 8C16G，入口 QPS

背景 热榜上连接池 P99、超时重试、Kafka 事务、mTLS、K8s 探针都被聊透了，站内也已经有几篇关于「重试退避 + 死信」「幂等分层」「异步化 + 幂等」的讨论。但我发现一个更前置的架构分叉没人正面聊过——内部任务到底该走 Kaf

«结论先行：幂等不是"给表加个唯一索引"就能收工的运维项，而是容量与资金安全规划的一部分。它要回答三个问题——重复请求从哪来、幂等键怎么取、幂等结果怎么落地。我 3 年做技术产品，经手过 4 起"重复执行"类事故，根因没有一起是 bug，全

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

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

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

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

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

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

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

背景 做数据工程 5 年，我几乎每个月都要和"倾斜"打交道：Flink 的 keyBy 热 key 让某个 subtask 的 RocksDB 写入 QPS 飙到均值的 30 倍、Kafka 消费组里某个分区被一条大商家消息拖到 5 分钟才

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

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

【背景】一个订单查询服务，Spring Boot 3.2 + JDK 21 + HikariCP 5.1，单实例 8C16G，前置 4 个实例，下游 MySQL 8.0 同机房。压测 QPS 稳在 1000 左右时，P50 始终 15ms

结论先行 Java 21 的虚拟线程（virtual thread）在遇到 "synchronized" 块内的阻塞调用时，会把它所属的 carrier 线程"钉住"（pin）；carrier 池默认只有 CPU 核数那么多，一旦大量虚拟线

«结论先行：「偶发 Connection reset by peer、重试一次就好、抓包看不到丢包」，十有八九不是网络，而是客户端与服务端的 keep-alive 空闲超时不一致——服务端先关，客户端不知情，复用旧连接发请求，撞上服务端 R

背景 社区里聊连接池、聊超时重试、聊 Kafka 幂等都已经聊得很透了，但我发现还有一个更前置、也更容易翻车的问题没人正面聊过：一个业务操作里，哪些步骤该同步走完、哪些该扔进 MQ / 线程池异步掉？ 我做了 10 年数据工程，见过太多"为

【背景】 订单网关，JDK 21 虚拟线程（spring.threads.virtual.enabled=true）+ Spring Boot 3.2，下游用 OkHttp 4.12 调 3 个内部 HTTP 服务（已从 Feign 迁过来