可以使用Apache Kafka“无限保留策略”作为带有CQRS的事件源系统的基础吗？

Question

我目前正在评估设计/实现事件源CQRS系统设计架构方法的选项。由于我们想将Apache Kafka用于其他方面（正常的发布子消息流处理），下一个逻辑问题是，“我们可以将Apache Kafka存储用作CQR的事件存储吗？”？，或者更重要的是，这是一个明智的决定吗？

现在我对此不确定。这一消息来源似乎对此表示支持：https://www.confluent.io/blog/okay-store-data-apache-kafka/

另一个消息来源建议：https://medium.com/serialized-io/apache-kafka-is-not-for-event-sourcing-81735c3cf5c

在我当前的测试/实验中，我遇到了与第二个来源描述的问题类似的问题，这些问题是：

1. 重组实体：Kafka似乎不支持快速检索/搜索主题内的特定事件（例如：与订单历史相关的所有命令-重建实体实例所必需的命令，似乎需要扫描所有主题事件，并仅过滤与某个实体实例标识符匹配的事件，这是不可行的）。[另一个人似乎得出了类似的结论：查询Kafka主题以获得具体记录——也就是说，这是不可能的（不依靠一些黑客技巧）]
2. -写一致性：Kafka不支持其存储上的事务原子性，因此在异步将事件导出到Kafka队列之前，通常只使用一些锁定方法（通常是乐观锁定）放置数据库（虽然我可以接受，但第一个问题对我来说更为关键）
3. 划分问题：在Kafka文档中，提到“顺序保证”仅存在于“主题的划分”中。同时，他们还说分区是并行性的基本单元，换句话说，如果您想并行化工作，请在分区（当然还有代理）之间传播消息。但这是一个问题，因为事件源系统中的“事件存储”需要顺序保证，所以这意味着如果我绝对需要顺序保证，那么我只能在这个用例中使用1个分区。这是正确的吗

尽管这个问题有点开放，但实际上是这样的：您是否使用Kafka作为事件源系统上的主事件存储？您如何处理从命令历史记录中重新组合实体实例的问题（假设该主题有数百万个条目，扫描所有集合不是一个选项）？您是否只使用了1个分区，从而牺牲了潜在的并发消费者（假设订单保证仅限于特定的主题分区）？

任何具体或一般的反馈都将不胜感激，因为这是一个复杂的主题，需要考虑几个因素。

提前谢谢。

编辑6年前这里有一个类似的讨论：将Kafka用作（CQRS）事件存储。好主意当时的共识也存在分歧，很多人认为这种方法很方便，他们提到Kafka是如何处理大量实时数据的。然而，问题（至少对我来说）与此无关，而是与Kafka重建实体状态的能力有多不方便有关——要么将主题建模为实体实例（主题数量呈指数级增长是不需要的），要么建模主题或实体类型（主题内的事件数量使重建非常缓慢/不实用）。

Answer 1

我在几个使用Kafka作为长期存储的项目中，Kafka对此没有问题，特别是最新版本的Kafka，他们引入了称为分层存储的东西，它使您可以在Cloud环境中将旧数据传输到较慢/更便宜的存储。

您不应该太担心事务，在今天的IT中，还有其他概念需要处理，例如事件源、[边界上下文][3]是的，您在设计应用程序时应该有所不同，如何？，这段视频对此进行了解释。

但你们是对的，你们对查询这些数据的选择是有限的，最简单的方法是使用Kafka Streams和KTable，但这将是一个键/值数据库，所以你们只能通过主键询问有关数据的问题。

你的下一个最佳选择是在Akka投影等框架的帮助下实现CQR的查询部分，我写了一篇关于如何将Akka投影与Elasticsearch结合使用的博客，你可以在这里和这里找到。

Answer 2

您的理解基本正确：

1. kafka没有搜索。绝对不是按键。有一个寻找时间戳的方法，但它不完美，对你试图做的事情不好。
2. kafka现在实际上支持有限形式的事务（仅见一次），尽管如果您与kafka之外的任何其他系统交互，它们将毫无用处。
3. kafka中任何东西的单位（事件排序、可用性、复制）都是一个分区。同一主题的分区之间没有保证。

所有这些都不会阻止应用程序使用Kafka作为他们国家的真理来源，只要：

1. 你的问题可以“切分”到主题分区中，这样你就不在乎跨分区事件的顺序了

samza和（IIUC）kafka都用日志压缩的kafka主题返回其状态存储。在kafka offset的内部，消费者组管理存储为一个日志压缩主题，代理在内存中持有“物化视图”-当消费者偏移分区的所有权在代理之间移动时，新领导会重放分区以重建此视图。