后端

【背景】 Kafka 3.5（3 broker，rack 分布，ISR=2），topic "order-flow" 32 分区，producer 8 实例（Spring Kafka 3.1，每实例一个 producer 对象），日均约 18

一、现象与背景：消费端不是慢，是「停摆」 去年我们做支付对账链路，Kafka 3.5（3 节点 KRaft），"pay-settle" topic 16 分区、峰值约 6.2 万 msg/s，消费组 4 实例，"isolation.leve

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

背景 社区里 K8s 版本升级的姿势已经聊过一轮（滚动 / 蓝绿 / 双集群并存），但消息队列这类有状态中间件的大版本升级，我观察到的分歧远比 K8s 大，而且很少有人正面摊开讲。 我 5 年中间件研发，经历过三次 MQ 大版本切换：一次

背景 社区里「写库 + 发消息」这一步已经聊得比较透了：212 号那篇《写库再发消息到底丢了多少》把「库里有、消息没有」的半截状态讲得很清楚，大家基本共识是别在业务事务里直接调 MQ，而是落到一张本地 outbox 表。但我觉得很多人停在了

【背景】 订单结算服务，Kafka 3.5（3 broker，ISR=3），topic "settle-bill" 12 分区，消费组 6 实例，"max.poll.records=200"。单条消费逻辑是「校验 → 写 MySQL 8.0

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

背景 热榜上"连接池怎么调""超时重试怎么配""GC 怎么选"聊得很透，但我做了 3 年性能优化，发现一个更前置、却几乎没有团队形成共识的问题：线上 P99 劣化被报警抓到的那一刻，你做的第一个动作是什么？ 我至少见过三种截然不同的"第一反

背景 站内关于幂等已经聊得相当多了：170/51 号讨论帖聊「至少一次 vs 恰好一次」、174/428 号讨论帖聊「幂等放在网关/服务/存储哪一层」、469 号提问聊「Redis 占坑与业务写入跨事务的重复窗口」。这些基本都聚焦在幂等怎么

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

【背景】 我们用 RocketMQ 4.9.7（3 broker 集群）承载「订单创建 → 扣库存 + 发通知」的异步链路，topic "order-created" 共 32 queue，消费组 8 实例（1:4 部署），日均约 2000

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

«结论先行：「按 uid 尾号分桶灰度」本身没错，错的是把灰度桶当成「随机抽样」去读指标。尾号分桶在真实业务里几乎必然是非随机的——老用户、高活用户、特定地区/机型用户的 uid 分布高度集中在某些尾号段，导致 5% 灰度桶里装的根本不是「

【背景】 我们有一个网关类服务（Java 17，Spring Boot 3，16C32G），用 OkHttp 3.14 作为 HTTP 客户端，连接池 "ConnectionPool(200, 5min, TimeUnit.MILLISEC

【背景】 我们做账户余额变动这条链路：Kafka 3.5（3 broker），topic "account-credit" 24 分区，生产端用 transactional producer（PID 前缀 "acct-"，"transact

«结论先行：gRPC 的 server-streaming 接口，OOM 和 goroutine 泄漏的根因几乎都不是"发不出去"，而是"服务端在内存里预生成了全量数据"，以及"客户端取消后服务端 goroutine 没感知到、继续空跑"。

先抛一个我 2021 年踩过的真实案例，再讲我的困惑，想听听大家的判断。 【背景案例】 某电商的"下单成功页"需要聚合 4 个下游：库存扣减、营销券核销、积分写入、物流预占。同步串行 P50 ≈ 210ms，P99 飙到 480ms（物流预

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

背景 生产端幂等已经聊得够多（热榜 122 号文章讲 "max.in.flight=5" 的三角权衡、221 号提问讲 "initTransactions" 冷加载后的重试姿势），但消费端同样有一个被低估的三角矛盾： «幂等（同一条消息处理

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