事件溯源 - 为什么需要专门的事件存储？

Question

我第一次尝试实现事件源/CQRS/DDD，主要是为了学习目的，其中有事件存储和消息队列（例如 Apache Kafka）的想法，并且事件从事件存储 => Kafka 流出连接 JDBC/Debezium CDC => Kafka。

我想知道为什么需要一个单独的事件存储，因为听起来 Kafka 本身可以通过其主要功能和日志压缩或配置日志保留来实现永久存储来实现其目的。我应该将事件存储在 RDBMS 之类的专用存储中以馈送到 Kafka，还是应该直接将它们馈送到 Kafka？

Answer 1

许多有关事件溯源和cqrs的文献都来自 [领域驱动设计] 社区；其最早的形式CQRS被称为DDDD......分布式域驱动设计。

\n\n

领域驱动设计中的常见模式之一是拥有一个领域模型来确保持久存储中数据的完整性，也就是说，确保不存在内部矛盾......

\n\n

\n

我想知道为什么需要一个单独的事件存储，因为听起来 Kafka 本身可以通过其主要功能和日志压缩或配置日志保留来实现永久存储来实现其目的。

\n

\n\n

那么如果我们想要一个没有内部矛盾的事件流，我们如何实现呢？一种方法是确保只有一个进程有权修改流。不幸的是，这会给你带来单点故障——进程终止，一切都结束。

\n\n

另一方面，如果您有多个进程更新同一流，那么您就会面临并发写入、数据争用以及引入矛盾的风险，因为一个写入者尚无法看到另一个写入者做了什么。

\n\n

使用 RDBMS 或事件存储，我们可以通过使用事务或比较和交换语义来解决这个问题；如果存在并发修改，则尝试使用新事件扩展流将被拒绝。

\n\n

此外，由于其DDD传统，耐用存储通常被分为许多非常细粒度的分区（也称为“聚合”）。 一个购物车可能合理地有四个专用于它的流。

\n\n

如果 Kafka 缺乏这些功能，那么它将成为事件存储的糟糕替代品。 KAFKA-2260已经开放四年多了，所以我们似乎缺少第一个。从我从 Kakfa 文献中可以看出，它也不喜欢细粒度的流（尽管我检查已经有一段时间了，也许事情已经改变了）。

\n\n

另请参阅：Jesper Hammarb\xc3\xa4ck在 18 个月前撰写了有关此内容的文章，并得出了与此处表达的类似的结论。

\n