在事件采购中处理大量事件

Question

事件采购的CQRS看起来非常适合作为我们系统的架构，我们目前只关注一件小事：处理大量事件并处理大型事件存储。 / p>

我们目前的系统每天接收大约一百万个事件（目前与事件采购无关），如果我们要在更长的时间内存储它们，我们的活动商店可能会变得相当大但是如果我们经常转储/清除滚动快照，我们可能会失去事件采购的一大优势：有关系统历史和重播的信息。

在CQRS架构中处理此问题的常用方法是什么？这根本不是问题吗？我们只是在活动商店投放更多硬件，还是我们可以在架构设计层面做些什么？

Answer 1

我认为最常用的方法是使用快照和持久性读取模型。也就是说，除非您需要构建新的读取模型或更改现有模型的工作方式，否则您实际上并不经常重播您的事件。通过存储域对象的快照，您可以避免重播长事件流。

有人可能会说，存储快照和持久性读取模型与仅仅在没有事件源的情况下进行CQRS的情况完全不同。但是，如果您在阅读模型中犯了错误，或者需要获取新信息，或者有其他严格的审计要求，那么旧事件就会存在。

在我们的应用程序中，我们有许多业务价值低的事件，我们计划在执行期间大量清理事件，以便我们的事件日志保持较小。但我想，对于某些对象，我们仍然会回到快照和持久模型。

Answer 2

查看“活动流集”。是否存在具有生命周期的流，它们往往会在相对较短的时间内发生变异，然后在达到最终状态时死亡？如果是这样，这些流可以转移到更便宜的存储（备份）。您需要它们的唯一原因是为了重放目的，因此您可能希望使它们仍然可访问（尽管响应速度较慢）或保留压缩副本以便重放。在任何情况下，请确认是否有流可以移出事件存储或至少退出活动流集。

另一个选择是跨多个物理事件存储分区您的流。也许有一个可以使用的地理边界，或者可能有一些东西自然地划分它们（你所在的域通常提供提示）。这是你需要反思优势和劣势的事情。

此技术不仅限于事件来源。它同样可以应用于基于状态的模型（它只是数据）。