将Kafka用作（CQRS）事件存储。好主意？

Question

虽然我已经遇到卡夫卡之前，我刚刚意识到卡夫卡也许可以作为（基础）一CQRS，eventstore。

Kafka支持的主要观点之一：

事件捕获/存储，当然都是HA。

Pub / sub架构

重播事件日志的能力，使新订户可以在事件发生后向系统注册。

诚然，我不是100％精通CQRS /事件源，但是这似乎与事件存储应有的程度非常接近。有趣的是：关于Kafka用作事件存储，我实在找不到太多，所以也许我错过了一些东西。

那么，卡夫卡缺少什么东西可以使其成为一个好的活动存储库？能行吗？用它生产吗？对洞察力，链接等感兴趣

基本上，系统状态是根据系统曾经收到的事务/事件保存的，而不是仅保存系统当前的状态/快照（通常这样做）。（将其视为会计中的总帐：最终，所有交易都将达到最终状态）。这允许进行各种有趣的事情，但请仔细阅读提供的链接。

Answer 1

Kafka旨在成为一个消息传递系统，它与事件存储库有很多相似之处，但引述了它们的介绍：Kafka集群将所有已发布的消息（无论是否已被使用）保留一段可配置的时间。例如，如果将保留时间设置为两天，则在发布消息后的两天内，该消息可供使用，之后将被丢弃以释放空间。Kafka的性能相对于数据大小实际上是恒定的，因此保留大量数据不是问题。因此，尽管可以无限期地保留消息，但是期望消息将被删除。这并不意味着您不能将其用作事件存储，但是最好使用其他东西。看看EventStore作为替代方案。更新Kafka文档：事件源是应用程序设计的一种样式，其中状态更改以时间顺序的记录序列记录。Kafka对大量存储的日志数据的支持使其成为以这种样式构建的应用程序的绝佳后端。更新2使用Kafka进行事件采购的一个关注点是所需主题的数量。通常，在事件源中，每个实体（例如用户，产品等）都有事件流（主题）。这样，可以通过重新应用流中的所有事件来重构实体的当前状态。每个Kafka主题由一个或多个分区组成，每个分区都存储为文件系统上的目录。随着znode数量的增加，ZooKeeper也将带来压力。