消息队列与异步处理

同步架构（紧耦合）： 用户下单 │ ├──▶ 订单服务（~10ms） │ │ │ ├──▶ 库存服务（~20ms） │ │ └── 扣减库存 │ ├──▶ 支付服务（~200ms） │ │ └── 处理支付 │ ├──▶ 通知服务（~50ms） │ │ └── 发短信 │ └──▶ 积分服务（~30ms） │ └── 加积分 │ 用户等待：10+20+200+50+30 = 310ms 才能收到响应！ 任何一个服务超时 → 整个下单请求失败 ────────────────────────────────────────────── 异步架构（消息队列解耦）： 用户下单 │ ├──▶ 订单服务（~10ms） │ └── 写订单到 DB │ └── 发消息到 MQ → 立即返回！用户响应 10ms │ │ 消息队列（Kafka） │ │ │ ┌─────────┼─────────┐ │ ▼ ▼ ▼ │ 库存服务 支付服务 通知服务 │ (异步处理) (异步处理) (异步处理) 优势： ① 用户响应快（10ms vs 310ms） ② 服务解耦（通知服务宕机不影响下单） ③ 削峰填谷（突发流量由MQ缓冲） ④ 重试容易（消息可以重新消费）

Kafka 架构全景： Producer Kafka Cluster Consumer ┌──────────┐ ┌─────────────────────────────┐ ┌──────────────┐ │ Service │ │ Topic: order-events │ │ Inventory │ │ A │───▶│ ┌──────┐ ┌──────┐ ┌──────┐ │───▶│ Service │ │ │ │ │ P-0 │ │ P-1 │ │ P-2 │ │ │ (Group A) │ └──────────┘ │ └──────┘ └──────┘ └──────┘ │ └──────────────┘ ┌──────────┐ │ │ ┌──────────────┐ │ Service │ │ Topic: payment-events │ │ Notification │ │ B │───▶│ ┌──────┐ ┌──────┐ │───▶│ Service │ │ │ │ │ P-0 │ │ P-1 │ │ │ (Group A) │ └──────────┘ │ └──────┘ └──────┘ │ └──────────────┘ └─────────────────────────────┘ ┌──────────────┐ │ Analytics │ │ (Group B) │ └──────────────┘ 同一 Topic 可以被多个 Consumer Group 独立消费！

Partition 内部结构（有序 + 可回放）： Partition 0： ┌──────┬──────┬──────┬──────┬──────┬──────┐ │ 0 │ 1 │ 2 │ 3 │ 4 │ 5 │ ← Offset │order │order │order │order │order │order │ │#1001 │#1002 │#1003 │#1004 │#1005 │#1006 │ └──────┴──────┴──────┴──────┴──────┴──────┘ ↑ Consumer A 当前消费到这里（Offset=3） 可以 Seek 回到 Offset=0 重新消费（回溯重放！） Consumer Group 并行消费（3个Partition，3个Consumer）： Partition 0 ──▶ Consumer 1（并行） Partition 1 ──▶ Consumer 2（并行） Partition 2 ──▶ Consumer 3（并行） 吞吐量 = 单 Consumer 吞吐 × Partition 数量

场景：订单支付消息可能被重复消费 方案一：幂等 Key + 去重表 ┌─────────────────────────────────────────┐ │ 消费消息前，先查去重表 │ │ │ │ SELECT id FROM processed_messages │ │ WHERE message_id = 'msg-uuid-123' │ │ │ │ IF 存在 → 跳过（已处理过） │ │ IF 不存在 → 处理 + INSERT 去重记录 │ └─────────────────────────────────────────┘ 方案二：数据库唯一约束 ┌─────────────────────────────────────────┐ │ INSERT INTO payment_records │ │ (order_id, amount, status) │ │ VALUES (123, 100.00, 'PAID') │ │ ON CONFLICT (order_id) DO NOTHING │ │ │ │ 重复消费 → INSERT 失败 → 安全忽略 │ └─────────────────────────────────────────┘ 方案三：乐观锁版本号 ┌─────────────────────────────────────────┐ │ UPDATE orders SET status='PAID', │ │ version=version+1 │ │ WHERE id=123 AND version=5 │ │ │ │ 只有当前版本匹配才更新，重复处理无效 │ └─────────────────────────────────────────┘

以「电商下单」为例的事件驱动流程： ┌──────────┐ │ Order │──发布──▶ OrderCreated { orderId, userId, items, total } │ Service │ └──────────┘ │ ┌───────────────────┼───────────────────┐ ▼ ▼ ▼ ┌────────────┐ ┌──────────────┐ ┌────────────────┐ │ Inventory │ │ Payment │ │ Notification │ │ Service │ │ Service │ │ Service │ │ │ │ │ │ │ │ 订阅事件 │ │ 订阅事件 │ │ 订阅事件 │ │ 扣减库存 │ │ 发起支付 │ │ 发邮件/短信 │ └────────────┘ └──────────────┘ └────────────────┘ 事件驱动的好处： ① Publisher 不需要知道 Subscriber 是谁（解耦） ② 新增服务只需订阅 Topic，不修改原有代码（开闭原则） ③ 审计日志天然完整（所有事件都记录在 Kafka 中）

Saga 编排模式（Choreography）： ① CreateOrder → 发布 OrderCreated 事件 ② InventoryService 订阅 → 扣减库存 → 发布 InventoryReserved ③ PaymentService 订阅 → 扣款 → 发布 PaymentCompleted ④ NotificationService 订阅 → 发短信 失败补偿： ③ 如果 PaymentService 失败 → 发布 PaymentFailed ② InventoryService 订阅 PaymentFailed → 回补库存（补偿事务） ① OrderService 订阅 → 将订单标记为失败 优点：无中心控制器，真正去中心化 缺点：流程难以追踪，Debug 困难 ────────────────────────────────────────────────── Saga 指挥模式（Orchestration）： Saga Orchestrator（指挥者） │ ├──① 调用 InventoryService.reserveItem() │ ✓ 成功 ├──② 调用 PaymentService.charge() │ ✗ 失败 ├──③ 补偿：调用 InventoryService.cancelReservation() │ ✓ 补偿成功 └──④ 将订单标记为失败，通知用户 优点：流程清晰，易于监控和 Debug 缺点：引入中心化的 Orchestrator，可能成为瓶颈 实际应用： Uber 使用 Saga 处理行程创建（跨行程、司机、支付三个服务） Amazon 用 Saga 处理订单履行（跨库存、支付、物流）