事件采购和处理数据依赖性

Question

鉴于REST API具有以下操作，导致事件发布到Kafka：

• AddCategory
• UpdateCategory
• RemoveCategory
• AddItem（通过某个标识符引用类别）
• 的updateItem
• 的removeItem

多个用户可以同时使用REST API的环境，并且消费者必须都获得相同的事件。消费者可能长时间离线（超过一天）。可能会添加新的消费者，并删除其他消费者。

问题：

• 事件排序（仅解决单个主题/分区？）
  1. AddCtem在AddCategory之前，无效的类别引用。
  2. 在AddCategory之前的UpdateItem，曾经是一个有效的引用，现在无效。
  3. AddItem之前的RemoveCategory，类别引用无效。
  4. ....其他并发问题的无限列表。
• 事件存储快照，用于快速重新同步重新启动的使用者
  1. 两个类别和项目是否都有压缩的日志主题，每个实体都由其标识符键入？
  2. 可以将整个压缩的日志主题以某种方式标识为偏移量吗？
  3. 压缩日志主题中是否只有一个条目，并且其数据包含所有类别的序列化blob和给定偏移的项目（需要单个主题/分区）。
  4. 如何处理从重播实体事件存储到命令/事件的“实时流”的切换？在压缩日志视图中的每个项目中编码偏移量，并将其传递给实时事件日志中的重播？

还有其他系统更适合这个问题吗？

Answer 1

根据我在活动采购方面的经验，我会给你一个部分答案。

  

事件排序（仅解决单个主题/分区？）

     

  

1. AddCtem在AddCategory之前，无效的类别引用。

  

2. AddCtem之前的UpdateItem，曾经是一个有效的引用，现在无效。

  
3. AddItem之前的RemoveCategory，类别引用无效。
  
4. ....其他并发问题的无限列表。
  

所有可扩展的事件存储，我知道仅在分区内部进行的保证事件。在DDD术语中，事件存储通过按生成顺序重放事件来确保正确地重新水合聚合。 Apache-kafka主题似乎是一个不错的选择。虽然这对于应用程序的写入端来说已经足够了，但是Read端更难以使用它。更难但不是不可能。

鉴于事件已经由Write端验证（因为它们代表已经发生的事实），我们可以确定系统中出现的任何不一致是由于事件的错误排序。此外，鉴于Read端最终与Write端一致，丢失的事件最终将到达我们的Read模型。

首先，在你的情况下AddItem before AddCategory, invalid category reference，事实上应该是ItemAdded before CategoryAdded（条款是过去的）。

其次，当ItemAdded到达时，您尝试按ID加载类别，如果失败（因为延迟的 CategoryAdded事件），那么您可以创建一个{ {1}} ID等于NotYetAvailableCategory事件中引用的ID，标题为“Not Yet Available请等待几毫秒”。然后，当ItemAdded事件到达时，您只需更新引用该类别ID的所有CategoryAdded。 因此，主要想法是您创建临时实体，这些实体将在其事件最终到达时完成。

对于Items，当CategoryRemoved before ItemAdded, category reference invalid事件到来时，您可以检查该类别是否已删除（通过ha ItemAdded读取模型）然后采取相应的操作您的ListOfCategoriesThatWereDeleted实体 - 取决于您的业务。