给定一个rest api，其中包含以下操作，导致事件发布到kafka：
添加类别
更新类别
删除类别
additem（通过某个标识符引用一个类别）
更新项目
删除项目
以及多个用户可以同时使用restapi的环境，消费者必须获得相同的事件。消费者可能会离线一段时间（超过一天）。可以添加新的消费者，也可以删除其他消费者。
问题是：
事件排序（仅解决单个主题/分区的问题？）
addcategory前的additem，类别引用无效。
addcategory之前的updateitem，以前是有效引用，现在无效。
removecategory在additem之前，类别引用无效。
……其他并发问题的无限列表。
用于重新启动的使用者快速重新同步的事件存储快照
类别和项目是否都应该有一个压缩的日志主题，每个实体都由其标识符键入？
整个压缩日志主题是否可以以某种方式标识为偏移量？
如果压缩日志主题中只有一个条目，并且其数据包含给定偏移量的所有类别和项的序列化blob（将需要单个主题/分区）。
如何处理从重放渲染实体事件存储到命令/事件“实时流”的切换？对压缩日志视图中每个项的偏移量进行编码，并将其传递给实时事件日志中的replay？
还有其他系统更适合这个问题吗？
1条答案
按热度按时间rlcwz9us1#
我会根据我在活动采购方面的经验给你一个部分答案。
事件排序（仅解决单个主题/分区的问题？）
addcategory前的additem，类别引用无效。
addcategory之前的updateitem，以前是有效引用，现在无效。
removecategory在additem之前，类别引用无效。
……其他并发问题的无限列表。
我知道的所有可伸缩事件存储都只在分区内排序。在ddd术语中，事件存储区通过按事件生成的顺序重放事件来确保聚合正确地重新水化。Apache-Kafka主题似乎是一个很好的选择。虽然这对于应用程序的写端来说已经足够了，但是对于读端来说使用它就更困难了。更难但并非不可能。
假设事件已经由写端验证（因为它们表示已经发生的事实），我们可以确定系统中出现的任何不一致都是由于错误的事件顺序造成的。另外，假设读端和写端最终是一致的，丢失的事件最终会到达我们的读模型。
所以，首先，在你的情况下
AddItem before AddCategory, invalid category reference，应该是事实ItemAdded before CategoryAdded（术语已过时）。第二，什么时候
ItemAdded到达时，您尝试按id加载类别，如果失败（因为延迟）CategoryAdded事件），然后可以创建NotYetAvailableCategoryid等于中引用的id的ItemAdded事件和标题“尚未可用，请稍等几秒钟”。然后，当CategoryAdded事件到达时，您只需更新所有Items因此，主要思想是创建临时实体，当它们的事件最终到达时，这些实体将被最终确定。如果是
CategoryRemoved before ItemAdded, category reference invalid，当ItemAdded事件到达时，您可以检查类别是否已被删除（由havind aListOfCategoriesThatWereDeleted阅读模型），然后采取适当的行动Item实体-什么取决于你的业务。