发布订阅与事件流的能否重放之别

事件驱动架构有两种主流模型，区别在于事件被消费之后还在不在：发布订阅模型下，事件发出去被订阅者收走就结束了，新加入的订阅者拿不到过去发生过的事件，典型实现是 RabbitMQ；事件流模型把事件持久化成一份有序的日志，消费者不是”订阅”而是可以从日志的任意位置开始读，新加入的客户端能拿到全部历史事件，事件还能被重放，典型实现是 Kafka。这个差异决定了两者适合的场景完全不同——发布订阅适合”通知类”场景（下单了、发货了，各方各自响应一次就够），事件流适合需要回溯历史、做实时数据管道或事件溯源的场景。发散：能不能重放事件，本质上是”消息是转瞬即逝的通知”还是”事件是可以被反复查阅的历史记录”这两种世界观的分野——选错了模型，后续想加一个”需要看历史全量事件”的新消费者时会发现架构本身就不支持，这是设计初期就该想清楚而不是后补的决策。