事件采购 - 事件回放

我一直在阅读关于事件采购模式，如果您想重建您的系统，这可能非常有用。但是，如果我需要在处理新的传入请求时运行事件重建，该怎么办？这种情况下是否有特定的模式或最佳做法？因此，如何确保新的传入请求不会在重播时堵塞我的系统，因为事件同步和顺序对我的系统非常重要。它涉及更新依赖于事件序列的数据库记录。有什么想法吗？事件采购 - 事件回放

来源

2016-11-22 Nyamnyam

这似乎是一个非常类似的问题我的http://stackoverflow.com/questions/38197712/event-sourcing-avoid-projects-duplicated-events-while-replaying-events-and-list – martinezdelariva

由于您描述的限制，听起来好像住从零重建不能成为您计划的一部分。您可以改为进行A/B设置，在当时处于脱机状态的新系统上播放事件，然后在新系统启动后切换到新系统。关键是旧系统和新系统可以同时调谐到事件流。

如果您订购了不同系统的事件子集，可能只需要为其中一个子系统重播事件，并且在没有该子系统的情况下仍然可以满足您的同步/顺序需求。

您可以通过在数据中包含事件序列号并且如果还没有看到该事件，并具有依赖序列的服务延迟处理，可以防止作用于过时的信息。

来源

2016-11-22 15:37:53 rep

谢谢，这意味着为了确保新系统完成所有追赶工作，我需要安排一个小的停机时间并关闭旧系统，以确保没有更多新数据流入旧系统。然后，一旦确认新系统已完全追上，我将需要打开新系统。无论如何，我似乎都需要为我的服务安排一些停机时间，以确保数据的准确性。纠正我，如果我错了。 – Nyamnyam

我认为你是误会。事件日志是事件采购的真相源泉，而所有其他系统都只是事件消费者。停机时间不是必需的;这只是一个确保您对这种转换过程中如何处理事件感到满意的问题。 – rep

为了将您的事件投影到读取模型中，您需要使用某种类型的追赶订阅，例如EventStore提供的订阅。在这种情况下，您的新活动将被保存到商店，但不会立即投影。

但是，您必须认识到，您的用户将开始查看大量过时的数据，并根据不一致的读取模型进行操作。我宁愿避免这种情况，让系统重建。

我同意第一个答案，您可能希望与更新旧版本并行并在某个时间点进行切换并行建立新的读取模型，可能并非所有用户都优先。

来源

2016-11-24 19:21:22

如果可能，我们不希望将第三方库用于事件重播。 – Nyamnyam

EventStore不是图书馆http://www.geteventstore.com –

我在类似的情况下使用了CQRS + ES。我使用准备好的数据创建了投影，我只能更新，但不能重建。而且在每一个查询中，我都从这个快速构建了结果信息。

如果您需要执行一些较长的操作（如db中的更新），请使用sagas。在事件结束后生成事件 - >传奇 - >更新投影并生成事件2。

当然，事件收入和投影更新之间会有一些延迟。

了解更多关于您的系统以及这种变体是否足够适合您是非常有趣的。

来源

2017-12-13 14:38:24

事件采购 - 事件回放

回答

相关问题