我目前正在评估设计/实现事件源+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
在我目前的测试/实验中，我遇到了与第二个来源描述的问题类似的问题，这些问题是：
重组实体：kafka似乎不支持快速检索/搜索主题中的特定事件（例如：与订单历史相关的所有命令-重建实体示例所必需的命令，似乎需要扫描所有主题事件，并仅过滤与某个实体示例标识符匹配的事件，这是不允许的）[另一个人似乎得出了一个类似的结论：查询Kafka主题以获得具体记录——也就是说，这是不可能的（不依赖于一些黑客技巧）]
-写一致性：kafka在其存储上不支持事务原子性，因此在异步将事件导出到kafka队列之前，通常只使用某种锁定方法（通常是乐观锁定）放置db（尽管我可以接受，但第一个问题对我来说更为关键）。
分区问题：在kafka文档中，提到“订单保证”只存在于“主题分区”中。同时，他们还说分区是并行的基本单元，换句话说，如果您想并行化工作，请将消息分布在分区（当然还有代理）之间。但这是一个问题，因为事件源系统中的“事件存储”需要顺序保证，所以这意味着如果我绝对需要顺序保证，那么我只能为这个用例使用一个分区。是这样吗？
尽管这个问题有点开放，但实际上是这样的：您是否使用kafka作为事件源系统上的主事件存储？您如何处理将实体示例从其命令历史中重新组合出来的问题（假设主题有数百万个条目，扫描所有集合不是一个选项）？您是否只使用了一个分区来牺牲潜在的并发使用者（假定订单保证仅限于特定的主题分区）？
任何具体或一般性的反馈都将不胜感激，因为这是一个复杂的问题，需要考虑几个因素。
提前谢谢。
编辑：6年前这里也有类似的讨论：使用Kafka作为（cqrs）事件商店。好主意？当时的共识也存在分歧，很多人认为这种方法很方便，他们提到Kafka是如何处理大量实时数据的。尽管如此，问题（至少对我来说）与此无关，但更多的是与Kafka重建实体状态的能力有多不方便有关——要么将主题建模为实体示例（主题数量的指数级爆炸是不希望的），或者通过建模主题或实体类型（主题中的大量事件使得重建非常缓慢/不实用）。