Apache kafka 使用kafka和cassandra进行活动采购的类别预测

我正在使用卡桑德拉和卡夫卡进行活动来源，而且效果很好。但我最近才发现设计/设置中存在一个潜在的重大缺陷。简要介绍如何完成此操作：

聚合命令处理程序基本上是一个kafka使用者，它使用与主题相关的消息：

1.1当接收到命令时，它将加载聚合的所有事件，并为每个事件重播聚合事件处理程序，以使聚合达到当前状态

1.2根据命令和业务逻辑，然后将一个或多个事件应用于事件存储。这涉及到将新事件插入cassandra中的事件存储表。事件上印有聚合的版本号-对于新聚合，从版本0开始，使预测成为可能。此外，它还将事件发送到另一个主题以进行投影

1.3卡夫卡消费者将在这些事件发布后收听该主题。该消费者将充当投影仪。当接收到感兴趣的事件时，它将加载聚合的当前读取模型。它检查所接收事件的版本是否为预期版本，然后更新读取模型

这似乎效果很好。问题是我何时需要EventStore所称的类别投影。让我们以订单聚合为例。我可以很容易地项目一个或多个阅读模型公关订单。但是，如果我想有一个包含客户最后30个订单的投影，那么我需要一个类别投影

我只是在琢磨如何做到这一点。我很想知道是否有其他人在使用卡桑德拉和卡夫卡进行活动采购。我读过一些地方，有些人不鼓励这样做。也许这就是原因

---

我知道EventStore支持此内置功能。也许使用Kafka作为事件存储将是一个更好的解决方案。

对于这种体系结构，您必须在以下两者之间进行选择：

每种类型的全局事件流-简单 每个类型的分区事件流-可伸缩 除非您的系统具有相当高的吞吐量，例如，对于所讨论的流类型，持续时间内每秒至少有10秒或100秒的事件，否则全局流是更简单的方法。一些系统（如Event Store）通过具有非常细粒度的流（如每个聚合实例），但能够将它们按流类型/类别/分区、按多个流类型等组合成更大的流，以一种性能和可预测的方式，提供了这两个方面的最佳效果，虽然仍然很简单，只要求您跟踪单个全球事件的位置

如果你和卡夫卡一起去分区：

当处理需要进入相同模型的不同分区的事件时，投影代码将需要处理访问相同读取模型的并发使用者组。根据投影的目标存储，有很多方法可以处理这些事务、乐观并发、原子操作等，但对于某些目标存储来说，这将是一个问题 投影代码需要跟踪每个分区的流位置，而不仅仅是单个位置。如果您的投影从多个流读取数据，它必须跟踪许多位置。 使用全局流消除了这两个问题—性能通常可能足够好

在这两种情况下，您可能还希望将流位置放入长期事件存储中，即Cassandra-您可以通过让一个专用进程读取已分区或全局的事件流，并使用每个事件的全局或分区位置更新Cassandra中的事件来实现这一点。我对MongoDB有一个类似的事情——我有一个读取“oplog”并将oplog时间戳复制到事件中的过程，因为oplog时间戳是完全有序的

另一个选项是从初始命令处理中删除Cassandra，改为使用Kafka Streams：

已分区的命令流通过与已分区的聚合KTable连接来处理 计算命令结果和事件 原子上，KTable使用更改的聚合进行更新，事件写入事件流，命令响应写入命令响应流。 然后，您将拥有一个下游事件处理器，该处理器将事件复制到Cassandra中，以便于查询等，并且可以在为每个事件添加Kafka流位置的同时提供类别排序。如果您不想将Kafka用于长期事件存储，这有助于赶上订阅等。为了赶上进度，您只需尽可能多地阅读卡桑德拉的文章，然后从上一次卡桑德拉事件的位置切换到卡夫卡的流媒体。另一方面，卡夫卡本身可以永远存储事件，所以这并不总是必要的

我希望这有助于理解您可能遇到的权衡和问题。

>您的事件主题具有什么粒度？每个聚合类型有一个主题还是每个聚合实例有一个主题？鉴于卡夫卡不能扩展到数百万个主题，前者是正常的方法，意味着你已经准备好了你的类别。一个主题公关聚合类型。但是有3个分区。应用程序的两个实例表示同一个consumergroup中的两个消费者。但现在我一直在考虑一个解决方案，以使一个全球性的事件版本公关聚合类型。如果我将聚合事件发送到只有一个分区的主题pr聚合，那么我可以使用它并使用全局版本标记事件，然后将版本化事件输出到另一个主题。然后我考虑为这个主题设置一个consumergroup pr投影，并将投影的位置存储在数据库中。但这将失败3个分区。我现在唯一能看到的方法是，在消费者收听的主题上只有一个分区。但不确定这是否是最佳实践