消息队列

深入探讨事件驱动工作流引擎的设计与实现，包括事件总线、工作流编排、状态管理等

引言：为什么需要消息队列？ 在分布式系统中，消息队列（MQ）是实现服务解耦、异步处理、流量削峰的核心组件。但面对 Kafka、RabbitMQ、RocketMQ、Pulsar 等众多选择，如何做出正确的决策？ 本文将从架构设计、性能特性、运维成本三个维度，深度对比这些消息队列，帮助你在技术选型时做出明智的决定。 一、消息队列的核心应用场景 1.1 服务解耦 同步调用（紧耦合）： 订单服务 -> 库存服务 -> 支付服务 -> 物流服务 │ │ │ │ └─────────┴─────────┴─────────┘ 任一服务故障，整个链路失败 异步调用（松耦合）： 订单服务 ─┬→ 消息队列 ─┬→ 库存服务 │ ├→ 支付服务 │ └→ 物流服务 │ └→ 独立演进，互不影响 1.2 异步处理 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 // 同步处理：用户等待 3 秒 func CreateOrder(req *CreateOrderRequest) error { // 100ms：创建订单 if err := orderService.Create(req); err != nil { return err } // 2000ms：发送通知 notificationService.Send(req.UserID) // 1000ms：更新推荐 recommendService.Update(req.UserID) return nil } // 异步处理：用户等待 100ms func CreateOrderAsync(req *CreateOrderRequest) error { // 100ms：创建订单 if err := orderService.Create(req); err != nil { return err } // 发送消息，异步处理 mq.Publish("order.created", req) return nil // 立即返回 } // 消费者异步处理 func consumer() { for msg := range mq.Subscribe("order.created") { go func() { notificationService.Send(msg.UserID) recommendService.Update(msg.UserID) }() } } 1.3 流量削峰 正常情况： 1000 QPS ─→ 订单服务（1000 QPS）─→ 数据库（1000 QPS） 秒杀场景： 100000 QPS ─→ 消息队列（缓冲） ─→ 订单服务（1000 QPS）─→ 数据库（1000 QPS） ↓ 队列堆积（非阻塞） 二、主流消息队列深度对比 2.1 对比总览 特性 Kafka RabbitMQ RocketMQ Pulsar 架构模型 日志存储 交换机+队列 主题+队列 分层存储 吞吐量 百万级/秒 万级/秒 十万级/秒 百万级/秒 延迟 ms 级 μs 级 ms 级 ms 级 消息可靠性 高（多副本） 中 高 高 消息顺序 分区内有序 队列内有序 严格有序 全局有序 协议支持 自有协议 AMQP 自有协议 自有协议 运维复杂度 中 高 中 高 社区活跃度 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ 2.2 Kafka：日志收集与流处理之王 架构设计： ...

深入解析事件驱动架构的设计原理、实现模式和技术选型，帮助你构建真正解耦、可扩展的后端系统。

掌握微服务通信的核心模式，构建高效可靠的分布式系统。