高并发

«结论先行：「偶发 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 迁过来

【背景】 最近翻了社区几篇帖子——连接池从 200 调到 2000 反而雪崩的复盘、JDK 21 虚拟线程把 HikariCP 池打满、carrier 池大小怎么定——发现大家聊的全是「具体某个模型的参数怎么调」，但有个更上游的问题很少被正

背景 我负责一条实时 ETL 管道的核心组件：从 MySQL 读 50~200 万行增量数据做转换后写回目标库。JDK 17 + HikariCP 5.1，maxSize=20。触发方式是定时任务 + Kafka 事件双驱动，高峰期并发读连

结论先行 线上 Redis 连接被「莫名其妙断开」、客户端侧只看到 "Connection reset by peer" / "Connection closed"，第一嫌疑往往不是网络抖动、不是超时，而是 Redis 服务端主动 kill

«结论先行：InnoDB 的主键是聚簇索引的物理顺序，主键的随机性直接决定写入是顺序 IO 还是随机 IO。把 UUID v4 换成雪花 ID，同样的批量写入 P99 从 1.8s 降到 52ms，收益 35 倍——这不是"ID 格式"问题

【背景】 我负责一个支付编排服务（JDK 17 + Spring Boot 3，单机 8C16G，前置 4 实例，K8s cpu limit=4），对外 QPS 峰值约 1.5k，P99 目标 500ms。一次请求内会并行发起 4 个下游

结论先行 批量插入慢，十有八九不是 SQL 写得差，而是「一次只提交一条」+「驱动没把 batch 拼成 multi-row INSERT」+「每条都强制刷盘」三件事叠在一起。我们一个埋点落库服务，单机写入吞吐从 1200 行/s 提到 9

背景 我带了 15 年后端，一半时间在做高并发链路。最近帮一个团队做容量评审，他们面对一个下单接口 P99 从 80ms 抖到 1.2s 的问题，给出的方案是"把下单同步流程拆成消息队列异步化，前端改成轮询结果"。我当场泼了冷水：你这不是把

【背景】 我负责一个多租户 SaaS 的数据分析查询服务：JDK 17 + Spring Boot 3 + PostgreSQL 15（单主库，16C64G）+ PgBouncer（transaction 模式，pool_size=20/租

背景 我做了 8 年数据工程，长期泡在高并发链路的性能调优里。这几年我发现一个奇怪的现象：社区里关于"怎么把 P99 打下来"的文章汗牛充栋（连接池、超时重试、Kafka 幂等、慢查询都写透了），但很少有人正面回答一个更前置的问题——我们到

【背景】 我负责一个支付回调服务：Spring Boot 3.2 + JDK 21（spring.threads.virtual.enabled=true，未额外调 carrier）+ MySQL 8.0 + Redis 7 + gRPC（

【背景】 高并发系统里，"把同步调用改成异步"大概是出现频率最高的性能优化建议。RT 从 80ms 降到 15ms，P99 从 300ms 降到 60ms，压测报告一片绿——然后呢？ 我最近帮一个团队做 review，他们的订单支付链路：创

【背景】 我负责一条实时用户行为聚合管道：Kafka 24 分区 → Flink 1.17（keyBy(user_id) + 滑动窗口 1min + UDAF 多指标聚合）→ 结果写 Redis Cluster。Flink 配置 8 个 s

【背景】 高并发场景下，幂等不是一个"加个唯一索引"就能收工的事。网络抖动、客户端 SDK 重试、网关重试、MQ 重投——同一个业务请求可能以不同形态到达后端 2~5 次。我见过最离谱的一次：客户端重试 + 网关重试 + MQ 重投叠加，一

【背景】 我负责一条实时指标聚合管道：Kafka 12 分区 → Flink 1.17（keyBy(user_id) + TumblingWindow 5min + UDAF 多指标聚合）→ 结果写 Redis。状态后端用 RocksDB（

结论先行：热 key 的根因不是「Redis 慢」，而是集群分片均衡被单 key 击穿——所有读都落在同一个分片上，其余 7 个分片在空转。解法不是加机器、不是调 Redis，而是把 90% 的读拦在应用进程内（本地缓存），用一致性令牌控制

结论先行 先给结论：在一台 8 物理核 / 16 逻辑核的机器上，8 个线程各自累加一个 "long" 计数器，如果这些计数器在堆内存里"挨着"，总吞吐只有 1180 万 ops/s；把它们各自撑到独占一条 64 字节缓存行之后，同一台机器

背景 做了 10 年性能优化，带过的团队里有一个反复出现的"信任危机"：压测报告写得很漂亮，P50 / P99 都达标，但一上真实流量，P99 就翻 2~3 倍。不是每次都这样，但每次遇到，排查起来都很痛苦——因为压测数据"看起来是对的"，