架构模式: 事务发件箱
同时被称作
Application events（系统事件）
上下文
服务命令通常需要更新数据库并发送消息/事件。例如，参与saga的服务需要以原子方式更新数据库并发送消息/事件。同样，发布域事件的服务必须以原子方式更新聚合并发布事件。数据库更新和发送消息必须是原子的，以避免数据不一致和错误。但是，使用跨越数据库和消息代理的分布式事务以原子方式更新数据库并发布消息/事件是不可行的。
问题
如何可靠地/原子地更新数据库并发布消息/事件？
关注点
- 可以不选择2PC
结论
使用关系数据库的服务将消息/事件作为本地事务的一部分插入到发件箱表（例如MESSAGE）中。使用NoSQL数据库的服务将消息/事件附加到正在更新的记录（例如文档或项目）的属性。单独的Message Relay进程将插入数据库的事件发布到消息代理。
结果上下文
这种模式具有以下好处：
- 该服务发布高级域事件
- 可以不选择2PC
这种模式有以下缺点：
- 由于开发人员可能忘记在更新数据库后发布消息/事件，因此可能容易出错。
此模式还存在以下问题：
- 消息中继可能会多次发布消息。例如，它可能在发布消息之后但在记录它已经这样做之前崩溃。重新启动时，它将再次发布消息。因此，消息使用者必须是幂等的，可能是通过跟踪它已经处理的消息的ID。幸运的是，由于消息使用者通常需要是幂等的（因为消息代理可以多次传递消息），这通常不是问题。
相关模式
- Saga和Domain事件模式创造了对这种模式的需求。
- 事件溯源是另一种解决方案
- 实现消息中继有两种模式：
- 事务日志拖尾模式
- 轮询发布者模式