Apache Kafka不适用于Event Sourcing!
Apache Kafka是一款很酷的产品，但如果你考虑将其用于事件溯源，建议你应该再考虑一下。
Kafka是一个在生产者和消费者之间传递消息的绝佳工具，可选的主题持久性能让你永久存储消息，是的，永远，如果你愿意。
因此，如果你的消息是事件，可以将Kafka用作事件存储或事件日志，但它实际上不适合用于事件溯源。
原因如下：
1. 加载当前状态
当服务收到请求对事件源实体进行状态更改的命令时，我们首先需要重新创建该对象的当前状态，我们通过从事件存储加载该特定实体ID的所有先前事件，然后将它们重新调用我们的领域对象中的相应方法，快速播放事件直到当前状态。
在Kafka中加载像这样的特定实体的事件并不容易。主题通常以 “ 订单 ”，“ 付款 ”或“ 通知 ” 等实体类型为中心进行分区，因此我们必须检查所有 “ 订单 ”的所有事件，并按其ID过滤它们以得到一个“ 订单”实体的状态，虽然这是可能的，但它并不实用。
一种替代方案是每个实体有一个主题，但我们最终可能会遇到数以千计的主题，而且最重要的是，订阅服务的下游需要一种方法来自动发现每个新实体的新创建的主题，这 不太实际。
2. 一致的写操作
当我们的实体状态被重新创建时，是时候执行传入命令所请求的业务逻辑了，如果业务逻辑失败，我们会向客户端返回错误，但如果成功则会发出新事件。在这种情况下，我们必须能够将新事件保存到我们的事件存储中，同时保证在此期间没有为此特定实体ID存储其他事件，否则我们可能会破坏领域对象的一致性。
OCC来救援
保证写入一致性的一种方法是利用事件存储的乐观并发控制，正确的事件存储为用户提供了一种方式，即“仅当实体的版本仍为x时才保存此事件”，Kafka不支持这一点，来自该领域专家的建议解决方法似乎是在其前面放置一个“数据库”以提供一致性控制点，虽然在某些情况下这个建议可能是一个可行的解决方案，但从长远来看，选择更适合特定问题的工具可能更明智。
3. 单写
获得一致性的另一种方法是确保序列化写入，即使用单写入器原则，这意味着我们确保关于特定实体ID的所有写入都发生在单个线程上。我们可以通过使我们的生产者堵塞等到其发布的事件被提交且可用，这种设计会对性能产生严重影响。
它适合吗？
那么，Kafka在事件源架构中是否有一席之地？也许，大概，它可能是你的事件存储的一个很好的补充，作为将事件传输到下游查询服务或读取模型的方式。
但是，在为我们的系统添加大量复杂的基础设施时，我们应该始终小心 - 所有这些都需要付出成本，因此请确保它足以满足你手头的问题！