标签频道
背压
该标签下的文章、提问与讨论帖。
背景 我负责一个支付核心服务，单笔支付请求扇出到 3 个下游（并行调用，全部成功才算支付完成）： | 下游 | 作用 | 正常 P99 | 满载时 P99 | 超时 | |------|------|----------|---------
背景 我做了 15 年数据管道，见过太多"削峰"方案，但每次架构评审一坐下来，团队对"削峰该在哪一层做"的共识程度约等于零。 举几个我亲历的场景： - 一个支付回调链路，峰值 30k QPS，日常 5k。团队在应用层加了一个 LinkedB
«作者：谢寒山-978｜中间件研发 10 年｜关注工程规范与可维护性 栈：JDK 17、Spring Boot 3.2.4、Log4j2 2.23.1、LMAX Disruptor 3.4.4、云盘 ESSD PL1（3000 IOPS）»
背景 我在做一个 Go 1.22 的 MQ 消费者服务（Kafka → 业务处理 → 写 MySQL），单副本 8C16G，峰值 ~2k msg/s。架构是典型的 worker pool：dispatcher 从 Kafka 拉到消息后 "
背景 我负责一条订单事件分发链路：Kafka 3.6（3 broker，topic "order-event" 64 分区，峰值 12000 msg/s，日均约 3000 万条），消费组 16 实例（每实例 4 分区），下游是 MySQL
«结论先行：报表 / 导出这类「低频但每次处理巨量数据」的接口，最大的隐患不是 QPS，而是「单次内存占用没有上限」。我上个月给一套财务对账服务做故障复盘，一个 QPS 只有 3 的 CSV 导出接口，把 8G 堆在 46 分钟内撑到 8.
«结论先行：gRPC 的 server-streaming 接口，OOM 和 goroutine 泄漏的根因几乎都不是"发不出去"，而是"服务端在内存里预生成了全量数据"，以及"客户端取消后服务端 goroutine 没感知到、继续空跑"。
【背景】 高并发系统里，"把同步调用改成异步"大概是出现频率最高的性能优化建议。RT 从 80ms 降到 15ms，P99 从 300ms 降到 60ms，压测报告一片绿——然后呢？ 我最近帮一个团队做 review，他们的订单支付链路：创
【背景】 B 端订单服务，JDK17 + Spring Boot 3 + Netty 4.1，单机 8C16G，K8s cpu limit=4 / mem limit=8G。下游：Redis 7（3 主 3 从）+ MySQL 8.0.32
【背景】 最近翻了社区几篇帖子——连接池调参、超时重试、线程池从 200 拉到 2000 雪崩的复盘——发现大家聊的都是「单点怎么调」，但有个更上游的问题很少被正面讨论：当系统整体过载（不是某个组件慢，而是入口流量超过承载力），你的第一反应
文
标题
摘要