使用Kafka流进行事件源

Question

我试图在Kafka流之上实现一个简单的CQRS/Event sourcing概念验证（如https://www.confluent.io/blog/event-sourcing-using-apache-kafka/所述）

我有4个基本部分：

events topic stream ->
group to a Ktable by aggregate ID ->
reduce aggregate events to current state ->
materialize as a state store

命令处理器-命令流，左与聚合状态KTABLE连接。对于结果流中的每个条目，使用函数（命令，状态）=>events生成结果事件，并将它们发布到events主题

问题是--有没有办法确保我在州存储中有聚合的最新版本？

如果一个命令违反了业务规则（例如，如果实体被标记为已删除，则修改该实体的命令无效），我希望拒绝该命令。但是，如果发布了DeleteCommand，之后紧跟一个ModifyCommand，则delete命令将生成DeleteDevent，但当处理ModifyCommand时，从状态存储区加载的状态可能不会反映这一点，并且将发布冲突事件。

我不介意牺牲命令处理吞吐量，我更愿意获得一致性保证（因为所有东西都是由相同的键分组的，并且应该在相同的分区中结束）

希望这是清楚的：）有什么建议吗？

Answer 1

我不认为Kafka对于CQR和事件来源是好的，正如您所描述的那样，因为它缺乏一种（简单的）方法来确保防止并发写入。本文对此进行了详细的论述。

我的意思是,您期望一个命令生成零个或更多的事件,或者在一个异常情况下失败；这是经典的事件源CQRS。大多数人期望这种建筑。

但是，您可以使用不同的样式来获取事件源。您的命令处理程序可以为接收到的每个命令产生事件（即DeletewasAccepted)。然后，事件处理程序最终可以以事件源方式（通过从其事件流重建聚合的状态）处理该事件，并发出其他事件（即itemdeleted或itemdeletedtionwasrejected)。因此，命令被触发并忘记，异步发送，客户端不会等待立即响应。但是，它会等待一个描述其命令执行结果的事件。

一个重要的方面是，事件处理程序必须以串行方式处理来自同一聚合的事件（精确地一次并按顺序处理）。这可以使用单个Kafaka消费者组来实现。你可以在这段视频中看到这个架构。