如何解决使用 Rocksdb 作为事件存储库的 Apache Kafka 事件溯源?
我对 kafka 和 RocksDB 作为事件存储的事件溯源有一些疑问。 我想用 Apache Kafka 实现事件溯源,我想到了这样做的想法:
- 为命令创建一个主题,其中使用aggregateID 作为关键字以确保排序
- 为使用aggregateID 作为确保排序的键的事件创建主题。其他服务可以使用此主题对这些事件采取行动。
- 创建一个状态存储 (rocksDB) 来持久化事件
保留事件:
我们可以通过为事件生成唯一的 id 来持久化事件。此 id 以聚合 ID 为前缀,并与 ULID(通用唯一字典可排序标识符)连接,例如customer-123@01FBDJAVZC04GWKGCKE6ZQXY5T 其中 customer-123 是聚合 ID,@ 之后的所有内容都是生成的 ulid(可排序)。 RocksDB 中的所有条目都按其键按字典顺序排序,因此通过生成这样的键,我们可以确保在我们读回事件以构建聚合状态时的顺序。同样,我们可以通过在rocksDB 中执行范围查询来读取给定aggregateID 的事件,例如store.range(from,to)。在这种情况下,范围查询将类似于: store.range("customer-123@","customer-123@z")。这样,我们将获得从 customer-123 开始到 customer-123 的最后一个事件的所有事件,因为 z 是字母表中的最后一个。
因此流应用程序将执行以下操作:
-
当一个命令进入时,它将使用范围查询(如上所述)从给定聚合 id 的 Rocksdb 加载所有事件。
-
如果命令有效,我们会创建一个或多个事件并将其保存到 RocksDB(如上所述),并将这些事件推送到事件主题,以便感兴趣的消费者可以对这些事件做出反应。
所以我的问题是:这是一个好方法吗?将所有事件持久化到本地状态存储是否可以?如果我们在加载聚合时进行大量范围查询,rocksDB 会遇到麻烦吗?是的,它将使用大量本地存储,但我们可以通过添加更多分区和节点来扩展它。
谢谢
解决方法
您需要意识到服务内部的事件与服务之间的事件不同。事件不应相同,因为这会造成硬耦合。
在服务内部,您可以使用事件溯源,而事件溯源适用于大多数数据库。您不在服务之间使用事件溯源。
在服务之间,我会考虑使用 Kafka 在服务之间进行事件通信。
通常您不需要对命令进行排队,尤其是在 Kafka 中,但可能仅用于审计目的。因为命令总是针对特定的服务/聚合。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。