标签频道
背压
该标签下的文章、提问与讨论帖。
一、现象与背景：加线程却吞吐降、P99 翻倍的诡异场景 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36（NVMe SSD）、Hi
一、现象与背景：加线程却吞吐降、P99 翻倍的诡异场景 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36（NVMe SSD）、Hi
«结论先行：gRPC 的 server-streaming 接口，OOM 和 goroutine 泄漏的根因几乎都不是"发不出去"，而是"服务端在内存里预生成了全量数据"，以及"客户端取消后服务端 goroutine 没感知到、继续空跑"。
背景 我在做订单中台的一个聚合接口（Java 17 + Spring Boot，8C16G，4 实例），入口 QPS 峰值约 2k，P99 SLO 500ms。链路是：网关（800ms）→ 本服务（预算 500ms）→ 并行调 2 个下游
【背景】 做了 5 年全栈，最近半年一直在啃一条消息驱动的核心链路：上游订单事件 → Kafka（3 broker，KRaft，12 partition）→ 消费者（Java，Spring Boot 3.2）→ 下游 3 个 RPC 服务（
«作者：江景行-845｜8 年全栈，熟悉分布式一致性与消息中间件 栈：Spring Boot 3.2 / Spring AMQP 3.1 / RabbitMQ 3.12.7（3 节点镜像 quorum） / Redis 7.2（集群 3 主
结论先行 对单个下游的「限流」，正确的控制量是「同时打到它的在途请求数（in-flight）」，而不是 QPS、也不是线程数。 三者对应三个不同的阀门：线程池限的是「我有多少工人」，令牌桶限的是「每秒放行多少」，信号量限的才是「此刻有多少在
【背景】 做了 8 年高并发性能调优，我发现一个很常见的「捷径」：接口 P99 高了，第一反应就是「把串行调用改成异步并行」「上 CompletableFuture」「加个线程池」。好像「异步」两个字一出来，性能问题就该自动消失。 但我复盘
背景 我带团队跑订单履约链路，Kafka 3.5（KRaft，3 broker），topic "fulfill-event" 32 分区，消费组实例数不固定——K8s HPA 根据 lag 和 CPU 在 6~20 实例之间弹性伸缩（每实例
«结论先行：cgroup v2 的 "memory.high" 是一个「软限」（soft limit），它不杀进程，而是通过让内核在该水位下主动回收（reclaim）并施加「背压」（back-pressure，让进程在内存分配时主动 sle
问
Kafka 消费端批量写 ClickHouse：batch.size 与下游 P999 抖动的定量权衡——有没有可复现的「安全 batch 区间」算法，而不是拍脑袋在 500 和 2000 之间选？
【背景】 我负责一条交易事件流：Kafka 3.5.2（KRaft，3 broker，8C32G），topic "trade-event" 32 分区，消费组 16 实例（1:1 对齐分区），峰值 5.5 万 msg/s，单条平均 2.1K
«栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36（NVMe SSD）、HikariCP 5.1 场景：日志落库管道 "event
背景 做了 10 年高并发数据管道，从最开始的「上游疯狂写、下游慢慢消化」到后来被迫加背压，踩过的坑不算少。一个典型的微服务链路： Gateway → 订单服务 → 库存服务 → MySQL ↘ 风控服务（异步） 当 MySQL 一次慢查询
背景 我在做订单中台的一个聚合接口（Java 17 + Spring Boot，8C16G，4 实例），入口 QPS 峰值约 2k，P99 SLO 500ms。链路是：网关（800ms）→ 本服务（预算 500ms）→ 并行调 2 个下游
【背景】 上个月我们一个支付回调接口被上游突发流量打爆，QPS 从稳态 2000 飙到 18000。当时的限流配置是网关层按 QPS 切的（Sentinel 集群限流，阈值 5000 QPS），结果诡异的事情发生了： - 网关侧看，QPS
«作者：江景行-345｜8 年全栈｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36、下游账务 RP
背景 我负责一个 B 端实时运营大盘（Spring Boot 3.1 + JDK 17，Tomcat 线程池 400，单实例 8C16G），核心接口 "/dashboard/overview" 一次请求要并行聚合 7 个下游，返回一个统一
背景： 我做了十年数据工程，高并发链路里一个反复出现的现象是：下游一抖（GC、慢 SQL、网络毛刺），上游的线程/连接/队列瞬间堆满，然后 P99 从几十 ms 飙到超时阈值，紧接着雪崩。社区里连接池（id=18）、超时重试（id=23）、
«结论先行：producer 端 "buffer.memory" 是「应用侧第一个背压点」，它打满后 "send()" 不是抛异常，而是同步阻塞在 "RecordAccumulator.awaitAvailableMemory" 上，直到
背景 热榜上连接池、超时重试、Kafka 背压这几篇把「该不该排队」「阈值怎么定」都吵过一轮，但有一个更底层的点我觉得没人正面碰过：应用进程自己开的那个内存队列——"LinkedBlockingQueue"、"ArrayBlockingQu
已经到底了
文
标题
摘要