标签: outbox-pattern

当我们需要更改两个系统中的数据时，双写入就会出现问题：数据库（SQL 或 NoSQL）和 Apache Kafka（例如）。必须可靠地/自动地更新数据库并发布消息。最终一致性是可以接受的，但不一致是不能接受的。

如果没有两阶段提交 (2PC)，双写入会导致不一致。

但在大多数情况下，2PC 并不是一个选择。

事务发件箱是一种微服务架构模式，其中单独的消息中继进程将插入数据库的事件发布到消息代理。

并行运行的多个消息中继进程会导致发布重复项（2 个进程读取 OUTBOX 表中的相同记录）或无序（如果每个进程只读取 OUTBOX 表的一部分）。

单个消息中继进程也可能多次发布消息。消息中继可能会在处理 OUTBOX 记录之后但在记录它已完成此操作的事实之前崩溃。当消息中继重新启动时，它将再次发布相同的消息。

如何在事务发件箱模式中实现消息中继，以便将重复消息或无序的风险降至最低，并且该概念适用于所有 SQL 和 NoSQL 数据库？

我正在研究使用发件箱模式创建事件流。我想知道为什么人们会选择发件箱模式而不是在所需的表上使用 CDC？

直接使用 CDC 的优点：

1. 流将始终按顺序排列，因为何时引入事件捕获并不重要，因为连接器会拍摄所有现有数据的快照并从此开始捕获事件。
2. 它不需要更改应用程序。应用程序可以继续按原样工作，无需更改任何代码。

缺点：

1. 需要手动解析数据库事件（或使用一些现有的解析器类，例如可用于发件箱事件的解析器类）。
2. 不过滤掉不必要的事件。例如。如果一条记录更改了 100 次，但只需要初始状态和最终状态，仍然会发出所有 100 个事件。选择性写入发件箱可以缓解这个问题。

在进一步阅读时，出现的一点是它将数据库设计与消息契约分开。然而，困扰我的缺点是发件箱从代码上线之日起就开始工作。对于所有以前的事件，它们需要重播并摄取到发件箱中，这会破坏流的顺序，因为较旧的事件将被描绘为发件箱中的最新事件，直接使用 CDC 时不必担心这一点。

关于这里的有效方法是什么有什么见解吗？