Apache Kafka的活动采购

Question

使用Kafka作为事件存储工作正常,它很容易将消息保留设置为无限制.

但我已经看到一些关于Kafka被用于事件采购的报道.这就是我对如何做到这一点感到困惑的地方.作为一个活动商店,我可以在那里推送我的消息.并根据需要消费或重播.

但对于事件采购,您很可能希望读取给定实体/聚合ID的事件.您当然可以使用分区,但这似乎滥用了这个概念,实际添加新实体很难,因为分区计数更多是在静态方面,即使您可以更改它.那里有没有明智的解决方案？Apache Kafka文档本身仅简要提及事件采购.

Answer 1

我认为 Apache Kafka 是存储事件源的最佳解决方案。事件溯源的概念非常接近，通常与 Greg Young 提出的名为 CQRS 的概念/实践一起使用，我建议您研究一下。

我在这个答案中使用的术语存储库是埃里克·埃文斯书中的领域驱动设计方面的存储库。

我想我知道你感到困惑的原因是什么。

但对于事件溯源，您很可能希望读取给定实体/聚合 ID 的事件。

我认为你的上述问题是正确的。但我认为你想表达一些不同的东西。你想表达这样的事情：

在事件溯源中，当要求存储库从其数据源检索对象时，存储库必须检索构成存储库的每个请求中的特定实体的所有事件。然后必须重播这些事件来构建对象。

这真的是你想表达的吗？因为上面这句话在我看来是错误的。

您不需要在每次检索对象时都重建该对象。

换句话说，每次从存储库检索对象时，您不需要重播构成该对象的所有事件。您可以在对象上播放事件并以不同的方式存储对象的当前版本，例如在缓存中，甚至更好，在缓存和 kafka 中。

那么我们来举个例子吧。假设我们有一辆正在装载和卸载的轨道/卡车。

事件的主流将是操作- 这将是我们应用程序中的第一个 kafka 主题。这将是我们的真相来源，正如杰伊·克雷普斯在他的论文中通常所说的那样。

这些是事件：

• 1号轨道上满是猪
• 2号轨道满载着猪
• 轨道2从猪身上卸下来
• 2号轨道装有沙子
• 轨道1从猪身上卸下来
• 轨道 1 满载着鲜花

最终的结果是，1号轨道上铺满了鲜花，2号轨道上铺满了沙子。

您要做的就是阅读该主题中的事件并填充第二个主题：trackUpdated。您流入trackUpdated主题的事件如下：

• 第一轨：猪
• 轨道2：猪
• 轨道2：什么都没有
• 赛道 2：沙子
• 曲目 1：什么都没有
• 第一轨：鲜花

同时，随着每条消息的消耗，您可以更新缓存（例如memcached）中卡车的当前版本。因此，memcache 将成为存储库用于检索跟踪对象的直接来源。

更重要的是，您使trackUpdated主题成为一个压缩主题。

阅读 Apache Kafka 官方文档中有关压缩主题的信息。Confluence 博客和 Linkedin Engineering 博客（在 Confluence 公司成立之前）上有很多关于它的有趣材料。

因此，由于trackUpdated已被 Kafka 兼容，一段时间后它看起来像这样：

• 赛道 2：沙子
• 第一轨：鲜花

如果您使用轨道 ID 作为所有消息的密钥，Kafka 将会执行此操作 - 请在文档中阅读消息“密钥”是什么。因此，每个曲目最终都会有 1 条消息。如果您在应用程序中发现错误，您可以重播操作主题以填充缓存并再次跟踪更新主题。如果您的缓存出现故障，您可以使用trackUpdated主题来填充您的缓存。

你怎么认为？强烈欢迎投票和评论。

更新：

(1) 经过一番思考，我改变了主意，认为你的引述是正确的。我现在发现是假的。所以我不认为（（认为对于事件溯源，您最有可能希望读取给定实体/聚合 ID 的事件。

当您在代码中发现错误时，您希望重播所有对象的所有事件。无论是像我的简单示例中那样有 2 个实体还是有 10M 个实体，都没有关系。

事件溯源并不是检索特定实体的所有事件。事件溯源是指您拥有所有事件的审核日志，并且能够重播它们以重建您的实体。您不需要能够重建单个特定实体。

(2)强烈建议熟悉Confluence和LinkedIn工程博客的一些博文。下面的内容对我来说非常有趣：

https://www.confluence.io/blog/making-sense-of-stream-processing/

https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

官方 Kafka 文档也是必须的。