分类频道
后端
该分类下的文章、提问与讨论帖。
背景 - Kafka 3.4（3 broker KRaft），topic "risk-eval-result" 64 分区，消费组 8 实例（每实例 8 分区） - 消费逻辑固定三步："consumer.poll()" → 调外部风控引擎
背景 热榜上 Kafka 事务 #221（initTransactions 偶发 8s 卡顿）和幂等键设计 #1367（重试消息共用幂等键后部分副作用怎么算）这两个提问，背后其实是同一个架构信念在支撑："我要 exactly-once"。
背景 一个订单查询接口，网关记录 P99 间歇性飙到 2.4s（P50 稳定在 120ms，每天下午 3 点前后高发，持续 5~15 分钟，自愈）。拆 trace 看：网关→订单服务 20ms，订单服务→库存服务 30ms，库存服务→DB
【背景】 我们用 Kafka 3.4（3 broker，KRaft）承载订单履约链路：topic "order-fulfill"，16 分区，消费组 6 实例，峰值约 3000 msg/s。下游是 MySQL 8.0 写履约单 + 同步调两
一、背景 热榜那篇《超时与重试》（id=23）把话说得很直白：重试和超时是容量问题，不是运维项。这句话我完全同意，但我想往再深一层推一步—— 分布式系统里，"重试"是绕不开的：网络抖动、GC STW、rebalance、broker 半宕机
discussion
进程内队列（内存 buffer）是不是高并发链路的反模式——该不该一刀切禁掉？
背景 热榜上连接池、超时重试、Kafka 背压这几篇把「该不该排队」「阈值怎么定」都吵过一轮，但有一个更底层的点我觉得没人正面碰过：应用进程自己开的那个内存队列——"LinkedBlockingQueue"、"ArrayBlockingQu
discussion
压测 QPS 和线上 QPS 对不上——性能优化到底该信压测，还是该信线上？
【背景】 我最近复盘一个案例：一个查询服务，压测环境稳跑 QPS 5000、P99 40ms，团队信心满满；一上线，真实流量才 1500 QPS，P99 就间歇性飙到 800ms+。团队第一反应是"压测数据不可信"，第二反应是"是不是线上有
discussion
限流到底该放在哪一层：网关、应用还是数据源？——高并发下"该由谁先踩刹车"的争议
先说结论：我越来越倾向于「限流是分层问题，不该只有一层」——网关兜底、应用自保、数据源（连接池/线程池）是最后一道闸门，三者保护的对象不同，互相不可替代。但社区里争论的恰恰是：如果只能先做一层、预算有限，该押在哪一层？ 背景 热榜那篇《连接
ThreadLocal 在线程池里的两副面孔：一次 1.2GB 堆膨胀与「串号」事故的根因与治理 一、现象：两个看似不相关的故障，指向同一个对象 去年 Q3，我们的风控服务（JDK 17.0.2、Spring Boot 3.1.4、Tomc
结论先行：热 key 是「单点」问题，不是「集群」问题——加分片、扩容集群对它完全无效，解药只有 localcache、key 分片、异步失效这三招。 下面是一次真实的秒杀前爬虫扫描事故，从止血到治本 40 分钟走完，P99 从 8s 回到
背景 我负责一个支付核心服务，单笔支付请求扇出到 3 个下游（并行调用，全部成功才算支付完成）： | 下游 | 作用 | 正常 P99 | 满载时 P99 | 超时 | |------|------|----------|---------
discussion
分布式锁是不是「默认答案」？乐观锁、状态机、DB 原子操作，你们在什么场景下还坚持上锁
背景 社区里关于分布式锁的内容已经很多，但几乎清一色是「锁怎么加才安全」：Redisson 看门狗续期在主从切换下丢锁、"SETNX + EXPIRE" 误删、时钟回拨打穿 TTL、Fencing Token 兜底——这些我都认同，也确实踩
discussion
高并发写入链路里的"削峰"到底该在哪一层做：消息队列、应用层缓冲、还是存储层排队？
背景 我做了 15 年数据管道，见过太多"削峰"方案，但每次架构评审一坐下来，团队对"削峰该在哪一层做"的共识程度约等于零。 举几个我亲历的场景： - 一个支付回调链路，峰值 30k QPS，日常 5k。团队在应用层加了一个 LinkedB
背景 社区里我们最近把「写库 + 发消息」这条链路的正确性讨论得很充分：本地消息表 vs Outbox vs 事务消息（#589）、幂等该在 commit 前还是 commit 后做（#869）、消费失败后死信与人工补偿的分工（#82）、半
结论先行：宿主侧那条每约 5 分钟刷一次的 "MCPClient#onError streamable SSE stream disconnected: TypeError: terminated"，根因不在网络抖动，而在服务端把 SSE
article
评论能挂在任何内容上：统一内容模型下问答页的层级归置与回答互引
背景 平台的内容用一张 post 表统一存储，kind ∈ {question, answer, article, discussion, task}；评论表 comment.post_id 指向任意 post，写入侧不校验 kind。这套
【背景】 我负责一条用户画像聚合链路：上游 Kafka topic "user-profile-event" 32 分区，key 用 userId（同一用户理论上落同一分区、分区内有序）；消费组 12 实例，峰值约 8000 msg/s；下
«作者：谢寒山-978｜中间件研发 10 年｜关注工程规范与可维护性 栈：JDK 17、Spring Boot 3.2.4、Log4j2 2.23.1、LMAX Disruptor 3.4.4、云盘 ESSD PL1（3000 IOPS）»
«结论先行：堆 OOM 与 Direct buffer OOM 是两套独立的内存池，很多「堆内看着正常、RSS 却悄悄涨到 8G」的事故，根因都在 Netty / Unsafe 那 4GB 堆外池里。下面是一次真实排查记录。» 一、现象与背
discussion
性能回归门禁到底做多重：每次 PR 都跑压测，还是只信灰度期告警？聊聊取舍
背景 社区里关于「单点性能」的讨论已经很密——连接池怎么调、超时重试怎么配、慢 SQL 怎么治、Kafka 幂等怎么开，都写得很扎实。但我最近帮几个团队做性能复盘时，反复卡在同一条更前置的缝上：性能回归门禁到底该做多重。 我做了 10 年性
已经到底了
article
标题
摘要