性能调优

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

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

结论先行 如果一次「正常流量压测全绿、合法输入 P99 只有几百纳秒」的校验接口，却在某天被几个恶意请求把整台机器 CPU 打满——第一嫌疑不是下游、不是 GC、不是连接池，而是那条你以为很普通的正则。我上个月在 UGC 服务上栽过：一个用

一、现象与背景 先给结论：这次毛刺的根因既不是 InnoDB、不是 binlog、不是网络，而是 Linux 内核的 page cache 回写策略——"vm.dirty_ratio" 默认 20% 在 32GB 内存的机器上等于允许 6.

一、现象：为什么我的 compacted topic 在删 key 后 30 分钟还在返回旧值 去年 11 月，我们给一个内部配置中心做了迁移：把原本走 ZK 的 key-value 配置搬到了 Kafka compacted topic（

一、现象：没人报警，但 INSERT 吞吐悄悄掉了 40% 背景：一套 MySQL 8.0.32 / InnoDB 的物流履约系统，核心表 "t_fulfillment_item"（履约明细），规模 4500 万行、单表数据 28.6GB、

【背景】 我负责一个支付网关服务：Spring Boot 3.2 + JDK 17（G1，"-Xmx4g"，tiered compilation 开启，默认参数）+ MySQL 8 + Redis 7，K8s 滚动发布，单副本 4C8G，Q

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

结论先行：读写分离里「我刚写完，读从库却是旧值」，根因不是代码 bug，而是主从复制是异步的——主库把 binlog 落盘就返回成功，从库要等 relay log 拉取 + 重放，中间这段窗口（毫秒到秒级）读从库必然读到旧数据。解法分两层：

【背景】 Spring Boot 3.2 + JDK 17 + MySQL 8.0 + HikariCP 5.1，池大小 20，connectionTimeout=3000ms，minimumIdle=5，maxLifetime=1800s

【背景】 我负责一条实时指标聚合管道：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 字节缓存行之后，同一台机器

背景：MySQL 8.0.34，InnoDB，业务库有一张订单流水表 t_order_flow（约 1.2 亿行，PK=id，二级索引 idx_merchant_time (merchant_id, created_at)、idx_stat

一、现象与背景 去年双11前压测，我们一个订单服务（Spring Boot 3.2，JDK 21，HikariCP 5.1.0，单实例 8C16G，前置 4 个实例）出现诡异故障：压测到 1200 QPS 时，大量请求在 30s 后超时，日

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

背景 在数据工程和后端高并发领域，"缓存和数据库不一致"几乎是每个团队都撞过的墙。但每次聊起来，发现大家的做法差异非常大，而且往往跟业务场景、团队规模、运维能力强相关——没有银弹，只有取舍。我做了 10 年数据工程，见过从"纯 TTL 兜底

MySQL 连接池打满不是 max_connections 的锅：一次 P99 从 80ms 飙到 12s 的复盘 一、现象与背景 2024 年 3 月，某中型电商订单服务在内部压测中出现了严重的性能退化： - 数据库：MySQL 8.0.

【背景】 B 端订单服务，JDK17 + Spring Boot 3 + Netty 4.1，单机 8C16G，K8s cpu limit=4 / mem limit=8G。下游：Redis 7（3 主 3 从）+ MySQL 8.0.32

一、现象与背景：连接数翻倍，接口反而更慢 先给结论：当瓶颈在 InnoDB 行锁排队时，把连接数加上去，QPS 会微涨、P99 会暴涨，因为新连接只是多排队的人，不是多干活的人。 具体场景：一个库存扣减服务，MySQL 8.0.32（16C