使用 Kafka 作为 (CQRS) Eventstore好主意？

如何解决使用 Kafka 作为 (CQRS) Eventstore好主意？

Kafka 旨在成为一个消息传递系统，它与事件存储有许多相似之处，但引用它们的介绍：

Kafka 集群会在 保留所有已发布的消息（无论它们是否已被使用） 。例如，如果将保留时间设置为两天，那么在消息发布后的两天内，它可以被使用，之后它将被丢弃以释放空间。就数据大小而言，Kafka 的性能实际上是恒定的，因此保留大量数据不是问题。

因此，虽然消息可能会被无限期保留，但期望它们将被删除。这并不意味着您不能将其用作事件存储，但使用其他东西可能会更好。查看EventStoreDB以获取替代方案。

更新

卡夫卡文档：

事件溯源是一种应用程序设计风格，其中状态更改被记录为按时间排序的记录序列。Kafka 对非常大的存储日志数据的支持使其成为以这种风格构建的应用程序的出色后端。

更新 2

使用 Kafka 进行事件溯源的一个问题是所需主题的数量。通常在事件溯源中，每个实体（例如用户、产品等）都有一个事件流（主题）。这样，可以通过重新应用流中的所有事件来重构实体的当前状态。每个 Kafka 主题由一个或多个分区组成，每个分区存储为文件系统上的一个目录。随着 znode 数量的增加，ZooKeeper 也会有压力。

解决方法

虽然我之前遇到过Kafka，但我最近才意识到 Kafka 可能被用作 CQRS 、
eventstore
的（基础）。

Kafka 支持的要点之一：

• 事件捕获/存储，当然都是 HA。
• 发布/订阅架构
• 能够重放事件日志，这允许新订阅者在事后向系统注册。

诚然，我不是 100% 精通 CQRS / 事件采购，但这似乎非常接近事件存储应该是什么。有趣的是：我真的找不到太多关于 Kafka
被用作事件存储的信息，所以也许我遗漏了一些东西。

那么，为了成为一个好的事件存储，Kafka 缺少什么？它会起作用吗？用它生产？对洞察力、链接等感兴趣。

基本上，系统的状态是根据系统曾经收到的事务/事件保存的，而不是像通常所做的那样仅保存系统的当前状态/快照。（把它想象成会计中的总账：所有交易最终加起来就是最终状态）这允许各种很酷的东西，但只需阅读提供的链接即可。