apache-kafka - 使用 Kafka 流进行事件溯源

Question

我正在尝试在 Kafka streams 之上实现一个简单的 CQRS/事件源概念证明。 (如 https://www.confluent.io/blog/event-sourcing-using-apache-kafka/ 中所述)

我有4个基本部分:

commands主题，它使用聚合 ID 作为按聚合顺序处理命令的键

events主题，聚合状态的每个更改都会发布到该主题(同样，键是聚合 ID)。此主题的保留策略为“永不删除”

KTable减少聚合状态并将其保存到状态存储

事件主题流 ->
按聚合 ID 分组到 Ktable ->
将聚合事件减少到当前状态 ->
实现为状态存储

命令处理器 - 命令流，左加入聚合状态 KTable。对于结果流中的每个条目，使用函数 (command, state) => events生成结果事件并将它们发布到 events话题

问题是 - 有没有办法确保我在 state store 中拥有最新版本的聚合？

如果违反业务规则，我想拒绝命令(例如 - 如果实体被标记为已删除，则修改实体的命令无效)。但是如果一个 DeleteCommand发布后是 ModifyCommand在它之后，删除命令将产生 DeletedEvent ，但当 ModifyCommand处理后，状态存储中的加载状态可能尚未反射(reflect)，并且将发布冲突事件。

我不介意牺牲命令处理吞吐量，我宁愿获得一致性保证(因为所有内容都按相同的键分组并且最终应该在同一个分区中)

希望这很清楚:) 有什么建议吗？

Answer 1

我不认为 Kafka 对 CQRS 和事件源有好处，就像你描述的那样，因为它缺乏一种(简单的)方法来确保防止并发写入。此 article详细讨论这个。

我的意思是你所描述的方式是你期望一个命令生成零个或多个事件或因异常而失败；这是具有事件源的经典 CQRS。大多数人都期待这种架构。

但是，您可以采用不同的风格进行事件采购。您的命令处理程序可以为收到的每个命令生成事件(即 DeleteWasAccepted )。然后，事件处理程序最终可以以事件来源的方式处理该事件(通过从其事件流重建聚合的状态)并发出其他事件(即 ItemDeleted 或 ItemDeletionWasRejected )。因此，命令被触发后忘记，异步发送，客户端不会等待立即响应。然而，它等待描述其命令执行结果的事件。

一个重要的方面是事件处理程序必须以串行方式(恰好一次且按顺序)处理来自同一聚合的事件。这可以使用单个 Kafka 消费者组来实现。您可以在此 video 中了解此架构.