后端

一、现象：一次秒杀活动，100 件库存卖出了 137 件 上个月我们上一场限时秒杀，目标是把某个 SKU 的 100 件库存放出去。活动开始后的 90 秒内，订单系统实际落库了 137 单，多扣了 37 件——这在库存层面意味着超卖 37%

背景 我 3 年中间件研发下来，发现团队里对「接口变更要不要上版本号」这个问题，几乎没有两个团队答案一样。有的团队所有接口永远 "/v1"，改字段就加个 "Deprecated" 硬扛三年；有的团队每个新需求都开一个 "/v2"、"/v3"

【背景】 Spring Boot 3 + JDK 17 + Kafka 3.5（4 分区）+ OpenTelemetry 1.32（Java Agent 接入）+ 自研线程池。业务链路：HTTP 入口 → 同步处理 → 发 Kafka →

背景：做异步链路时几乎绕不开一个选择题——消费端到底按「至少一次投递 + 业务幂等」来设计，还是去追框架宣传的「恰好一次（exactly-once）」？我带团队处理订单、支付、库存这类有副作用的链路时，反复在这个点上和新人、和别的团队掰扯，

结论先行 先给结论：订单列表接口 P99 从 340ms 压到 52ms，靠的不是加机器，而是把 "filesort" 从"磁盘临时表"拉回"内存排序"。两个关键旋钮是 "sort_buffer_size" 和 "priority_sort

背景：我在一个订单履约服务里用 Kafka（3.5，3 节点）做异步落库，消费组 4 个 consumer，topic 6 分区，平时 lag 基本在 0~50 之间。 现象：过去两周出现 4 次间歇性 lag 飙升，单次峰值到 18 万~

结论先行 P50 稳定、P99 间歇性飙 3 倍以上，CPU 不高、慢日志干净、连接池没打满——如果这几个条件同时满足，第一嫌疑不是数据库，是 GC。我 3 年里被「GC 毛刺」坑过两次，两次都是 G1 在 4G 堆上做的 Mixed GC

结论先行 超时和重试不是「加个配置就完事」的运维项，而是容量规划的一部分。我见过三次线上事故，根因都不是 bug，而是超时和重试配错了： 1. 上游 200ms 超时，下游 P99 是 180ms —— 平时没事，下游一次 GC 抖到 30

结论先行：连接池大小调成 CPU 核数的 10 倍、甚至 50 倍，往往不是变快，而是把抖动放大。下面是一次真实的 P99 抖动排查记录。 【现象】 一个订单查询接口，QPS 稳定在 800 左右，P50 一直 12ms，但 P99 间歇性

背景 社区里的文章、问答与评论都以 Markdown 存储，但详情页最初用 th:text 原样输出，读者看到的全是 ## 与 - 这类语法原文。要在不改动写入链路的前提下，让浏览侧渲染成 HTML，我们选了服务端渲染。 方案 - 渲染器：