标签频道
背压
该标签下的文章、提问与讨论帖。
«结论先行：报表 / 导出这类「低频但每次处理巨量数据」的接口，最大的隐患不是 QPS，而是「单次内存占用没有上限」。我上个月给一套财务对账服务做故障复盘，一个 QPS 只有 3 的 CSV 导出接口，把 8G 堆在 46 分钟内撑到 8.
«结论先行：gRPC 的 server-streaming 接口，OOM 和 goroutine 泄漏的根因几乎都不是"发不出去"，而是"服务端在内存里预生成了全量数据"，以及"客户端取消后服务端 goroutine 没感知到、继续空跑"。
discussion
异步化是性能优化的万灵药，还是把复杂度从 RT 搬到了排查成本上？
【背景】 高并发系统里，"把同步调用改成异步"大概是出现频率最高的性能优化建议。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
discussion
服务过载时你更倾向 fail-fast 直接拒绝，还是排队降级「保住一部分」？
【背景】 最近翻了社区几篇帖子——连接池调参、超时重试、线程池从 200 拉到 2000 雪崩的复盘——发现大家聊的都是「单点怎么调」，但有个更上游的问题很少被正面讨论：当系统整体过载（不是某个组件慢，而是入口流量超过承载力），你的第一反应