在生产环境中，事件数量大规模扩展，在紧急情况下，如果它们太多，可能需要几天才能重新运行所有处理程序？
答案 0 :(得分：1)
取决于您所描述的紧急情况
如果您的紧急情况的性质是您的事件处理程序大量落后于作者（例如：您的消息被阻止，并且您现在有48小时的积压等待您） - 并不多。如果您的消费者是可并行化的，那么您可以通过使用LMAX Disruptor等数据结构来加速并行恢复。
（模拟：你决定引入一个新的阅读模型，这需要处理大量积压的数据以达到正确的状态。没有任何“回答”，除了咀嚼它们。在某些情况下，你可能会能够根据一些可管理的事件数创建一个近似值，同时等待真正的答案完成，但没有处理所有事件的捷径。）
另一方面，如果历史很大，但积压是可管理的（即 - 写模型没有产生新事件），通常可以避免需要完整的重播。
在写模型中：大多数事件源解决方案利用支持多个事件流的事件存储 - 写模型中的每个聚合都有一个专用流。大量事件数通常意味着大量可管理的流。如果这是真的，你可以单独留下写模型 - 按需加载整个历史记录。
如果该假设不成立 - 写入模型的一部分具有极大的流，或者构成多个流事件的读取模型的一部分，通常的答案是快照。
也就是说，在健康的系统中，处理程序在某些时间表上保持其状态，并在元数据中包含一个标识符，该标识符跟踪历史记录中拍摄快照的位置。
要恢复，请重新加载快照和标识符。然后，您可以从该点开始重播（假设您有一个事件存储，允许您从历史记录中的任意点开始重播）。
因此，管理恢复时间只需调整快照时间间隔，这样您就可以在“最新”后面恢复SLA。快照的创建可以在完全独立的过程中进行。 （实际上，您的持久性快照存储看起来很像持久性读取模型）。