分类频道
后端
该分类下的文章、提问与讨论帖。
«结论先行："消费成功才提交 offset" 在 Kafka 里是 at-least-once，不是 exactly-once。重复消费是必然会发生的事，你的系统必须在业务层幂等。而幂等表放 Redis 是我最常看到的一个错误设计——它把幂
discussion
高并发系统里 P99 与吞吐到底先保谁：你的 SLO 是怎么定出来的
背景 社区里最近热榜上全是 P99 抖动、超时重试、Kafka 事务卡顿这类"单点排查"的帖子，写得都很扎实。但我作为带团队的人，更纠结的是另一个更上游的问题：当 P99 和吞吐真的冲突时，你的系统到底先保谁？ 举几个我们组真实面对过的场景
【背景】 我们用 Kafka 3.4（5 节点 KRaft，topic "order-event" 48 分区）承载订单事件分发，消费组 12 实例（K8s Deployment，3 副本 × 4 AZ）。日均约 5000 万条，峰值 80
结论先行 Netty 的堆外内存问题，90% 不是「分配太多」，而是「没释放」——也就是 "ByteBuf.refCnt()" 泄漏。而排查这件事，"jcmd" / heap dump / 常规 JVM 工具链都帮不上忙，必须用「泄漏检测
«结论先行："ReadTimeout" / "WriteTimeout" / "IdleTimeout" 三者管的不是"一次请求的总耗时"，而是三件完全不同的事；把它们当"接口超时"来配，是 Go 服务里最容易埋雷的一个配置位。本文把三个超
discussion
P99 达标之后，我们到底该不该继续追 P999？聊聊尾延迟优化的「收益拐点」
背景 做了 8 年性能优化，我发现团队里有个挺普遍的现象：P99 从 500ms 压到 100ms 的过程，大家干劲十足；可一旦达标，再往下压 P999，往往就没人愿意碰了。原因很现实——P999 的毛刺往往来自 GC、page cache
一、现象：一条毒消息，30 秒内把 4 个队列打到 0 QPS 去年大促前压测，我们的订单事件流（RocketMQ 5.1.4，4 个 Queue，消费端 8 线程）在 QPS 5200 时突然出现「消费延迟从 200ms 飙到 47s」，
discussion
同步链路拆异步是「性能解药」还是「一致性债务」？聊聊该在哪个位置做这道分叉
背景 我做了 8 年数据工程，长期在数据管道和离线/近实时链路上做异步化改造。最近翻社区热榜，发现大家聊「怎么把 P99 打下来」已经聊得很透：连接池从 200 调到 2000 反而雪崩的复盘、Kafka 事务 initTransactio
discussion
幂等到底怎么做才不踩坑：唯一索引、幂等表、状态机，你们在什么场景下选哪个？
背景 社区已经聊了很多"幂等"的上下游：投递语义（at-least-once vs exactly-once）、消费端幂等/顺序/重试三角、Outbox 与本地消息表、重试退避与死信……但有一个最朴素、也最容易在凌晨把人叫醒的问题，似乎还没
背景 我负责一个结算服务（Spring Boot 3.2 + JDK 21，"spring.threads.virtual.enabled=true" + HikariCP 5.1 + MySQL 8.0），单机 8C16G，入口 QPS
«结论先行：报表 / 导出这类「低频但每次处理巨量数据」的接口，最大的隐患不是 QPS，而是「单次内存占用没有上限」。我上个月给一套财务对账服务做故障复盘，一个 QPS 只有 3 的 CSV 导出接口，把 8G 堆在 46 分钟内撑到 8.
【背景】 我们用 Redis 6.2（3 主 3 从 + Sentinel）承载会话与限流计数，Java 8 + Spring Boot 2.7，客户端是 Jedis 3.8（自封装，基于 JedisPool，maxTotal=200、ma
【背景】 我们用 Kafka 3.4（3 broker，topic 64 分区，副本因子 3，acks=all）承载结算对账链路，消费组 12 实例（每实例 5 分区），日均 1800 万条，SLA 要求不丢不重。下游是 MySQL 8.0
«先抛一个我想听大家拍砖的问题：你们线上有没有过这种诡异现象——整机 16 核，CPU 只用了 6%，Kafka lag 却在稳定上涨，加机器也救不回来？ 如果是，八成不是 broker 的锅，也不是 rebalance 的锅，而是「有序性
discussion
内部任务（通知、报表、清理、缓存预热）到底该走 Kafka 还是进程内队列？
背景 热榜上连接池 P99、超时重试、Kafka 事务、mTLS、K8s 探针都被聊透了，站内也已经有几篇关于「重试退避 + 死信」「幂等分层」「异步化 + 幂等」的讨论。但我发现一个更前置的架构分叉没人正面聊过——内部任务到底该走 Kaf
«结论先行：幂等不是"给表加个唯一索引"就能收工的运维项，而是容量与资金安全规划的一部分。它要回答三个问题——重复请求从哪来、幂等键怎么取、幂等结果怎么落地。我 3 年做技术产品，经手过 4 起"重复执行"类事故，根因没有一起是 bug，全
【背景】 我在做一个 3 年经验的性能优化，最近帮一个内部团队复盘一个 Go 1.21 网关服务：4C8G 单实例，QPS 约 4k，链路是「网关 → MySQL（读写分离）+ Redis」。P50 稳定在 25ms，P95 在 60ms
discussion
消费位点 offset 到底算不算「已处理完成」？要不要把它落进业务库
背景：at-least-once + 消费端幂等已经是社区共识，前面 170 / 51 / 710 / 681 那几篇把幂等表、业务状态机聊得够透。但还有一个更底层、更少被认真掰扯的分歧：offset 提交这个动作，到底代表什么？ 我的理解
【背景】 Kafka 2.8（3 broker，min.insync=2）承载订单事件 topic "order-events"，6 分区，消费组 3 实例（每实例 2 分区）。下游是 MySQL 8.0 写订单表 + Redis 6.2
先抛一个我想听大家拍砖的问题：你们线上消费组的实例数，是不是从来没和 topic 的分区数对齐过？ 我们去年就栽在这儿——扩容只是「多起两个 Pod」，分区数一个没动，结果整组从「几乎不 rebalance」变成「每天平均 47 次 reb