消息与事件驱动：共同模型先于产品配置

把通知放进消息队列，接口就不必等邮件真正发出再返回。但任务交出去以后，还要知道有没有送达、能否重复执行、失败后怎么处理。本阶段先讲这些共同问题，再比较不同消息系统。

版本与资料依据

  • last_verified: 2026-08-24
  • version_scope: Kafka/RabbitMQ/RocketMQ concepts
  • source_type: official-docs
  • stability: version-sensitive

一条消息从生产者发出，经消息系统保存和分发，再由消费者处理。学习时先跟踪这条路：确认消息的 ack 在哪一步发出，失败会不会重投，重复消息是否产生重复结果。

之后再学习顺序、积压与回压、死信队列（DLQ）、消息格式变化以及 Outbox。Kafka、RabbitMQ 和 RocketMQ 的实现与配置不同，但选型前都要回答这些问题。

端到端语义

看到“恰好一次”时，要追问它保证的是哪一段。消息系统内部事务，并不会自动把消费者写数据库、调用外部接口也纳入同一个事务。常见设计是允许消息至少投递一次，由消费者处理重复，再通过 Outbox 协调业务写入与待发消息。

验收

练习时依次制造重复消息、乱序、确认前后崩溃、消息系统不可用、持续失败的消息和大量积压。为每次实验保留事件 ID、业务对象版本、尝试次数和处理结果；进入死信队列时，也要保存原因。最后检查业务数据，而不只看消息日志。

两个确认回答的是不同问题

以 RabbitMQ 为例，发布者收到确认，说明的是生产者到消息系统这一段；消费者确认则说明消费者这一段。前者不表示邮件已经发到用户邮箱。

练习：先让消费者暂停，发布一条消息，观察发布确认可以完成但业务尚未执行；再让消费者完成业务后、确认前退出，观察消息可能重新投递。最后给业务操作增加去重机制。把这三个现象连起来，才知道“收到了消息”与“完成了任务”之间还差什么。

本节的核验依据

2026-10-25 查阅。下面的链接支持本节的机制说明；练习场景和选型建议是本教程的教学设计。