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

虽然我之前碰到过 Kafka,但我最近才意识到Kafka可能被用作(基础) CQRSeventstore

Kafka支持的主要点之一:

>事件捕获/存储,当然是所有的HA。
> Pub / sub架构
>能够重播事件日志,允许新订阅者在事实之后向系统注册的能力。

诚然,我不是100%精通CQRS /事件源,但这似乎非常接近事件存储应该是什么。有趣的是:我真的找不到那么多Kafka被用作一个事件,所以也许我必须缺少的东西。

所以,卡夫卡什么失去了它是一个好的事件店?它会工作吗?使用它生产?感兴趣的洞察,链接等

基本上,系统的状态基于系统已经接收的事务/事件被保存,而不是仅仅保存系统的当前状态/快照,这是通常做的。 (认为​​它作为一个会计总帐:所有的交易最终合计到最终状态)这允许各种酷的东西,但只是阅读在提供的链接。

Kafka旨在成为一个与事件存储具有许多相似之处的消息系统,但是引用它们的介绍:

The Kafka cluster retains all published messages—whether or not they
have been consumed—for a configurable period of time. For example if
the retention is set for two days, then for the two days after a
message is published it is available for consumption, after which it
will be discarded to free up space. Kafka’s performance is effectively
constant with respect to data size so retaining lots of data is not a
problem.

因此,尽管消息可以无限期地保留,但期望是它们将被删除。这并不意味着你不能使用它作为事件存储,但它可能更好,使用别的东西。看看EventStore的替代品。

更新

Kafka documentation

Event sourcing is a style of application design where state changes are logged as a time-ordered sequence of records. Kafka’s support for very large stored log data makes it an excellent backend for an application built in this style.

更新2

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

相关文章
相关标签/搜索