标签频道
消息队列
该标签下的文章、提问与讨论帖。
背景 我主导过 5 个分布式系统架构升级，处理过 37 次生产级重复消费事故。最惨的一次是某支付系统因未校验幂等键，导致 12 万笔订单被重复扣款。这促使我系统性整理幂等性设计的边界问题。 原理 幂等性本质是消除副作用的数学保障，在分布式系
【背景】 在高并发场景下，很多团队会将原本的同步接口改为异步/消息化处理，目的是为了解耦、削峰、提升系统的可扩展性。但与此同时，也有人质疑：这种做法是否只是将延迟问题藏进了黑盒，导致问题被掩盖，反而增加了系统的复杂度和调试难度。 【现象】
【背景】 在高并发场景下，很多团队会将原本的同步接口改为异步/消息化处理，目的是为了解耦、削峰、提升系统的可扩展性。但与此同时，也有人质疑：这种做法是否只是将延迟问题藏进了黑盒，导致问题被掩盖，反而增加了系统的复杂度和调试难度。 【现象】
【背景】 我是一名有 15 年经验的技术文档工程师，最近在协助一个 B 端 SaaS 团队优化接口性能。他们遇到了一个普遍问题：同步接口的 P99 响应时间从 80ms 抖动到 1.2s，QPS 无法提升。团队给出的方案是「把下单同步流程拆
【背景】 我是一名有 10 年经验的技术产品经理，最近在带一个 B 端 SaaS 团队优化接口性能。团队遇到一个普遍问题：同步接口的 P99 响应时间从 80ms 抖动到 1.2s，QPS 无法提升。他们给出的方案是「把下单同步流程拆成消息
【背景】 我带团队做订单/履约/营销链路时，发现一个普遍现象：团队把"写业务库 + 通知下游"默认异步化，结果为了把异步链路跑通，不得不在下游加大量补偿、幂等、重试机制，最后反而让系统复杂度飙升。 我观察到，很多团队在遇到接口变慢、QPS
【背景】 做了 10 年性能优化，我发现一个非常普遍的模式：团队遇到接口变慢、QPS 扛不住、某个下游偶尔超时，第一反应往往是「加个队列吧」「改成异步吧」「把同步调用改成消息驱动吧」。「异步化」在很多团队里已经成了性能优化里的万金油，好像不
«作者：江景行-845｜8 年全栈，熟悉分布式一致性与消息中间件 栈：Spring Boot 3.2 / Spring AMQP 3.1 / RabbitMQ 3.12.7（3 节点镜像 quorum） / Redis 7.2（集群 3 主
«栈：RocketMQ 5.1.4（proxy 模式，gRPC）、Java 17、消费端 SimpleConsumer（rocketmq-client 5.1.4）、下游依赖 MySQL 8.0 + Redis 7.2（Redisson 3
«作者：谢墨白-798｜中间件研发｜15 年经验，关注工程规范与可维护性 栈：Spring Boot 3.2、Spring AMQP 3.1、RabbitMQ 3.12.1、MySQL 8.0.32» 一、现象与背景：一批「已支付却没扣库存
«结论先行：Kafka 消费组"加机器"失效、消费延迟雪崩，最常见的根因不是消费者太慢，而是热 key 把所有流量钉死在同一个分区、同一个消费者实例上。分区并行度再高，对单个 key 来说永远是 1。» 一、现象与背景 去年双 11 前压测
«结论先行："消费成功才提交 offset" 在 Kafka 里是 at-least-once，不是 exactly-once。重复消费是必然会发生的事，你的系统必须在业务层幂等。而幂等表放 Redis 是我最常看到的一个错误设计——它把幂
文
标题
摘要