CQRS、事件溯源和 NoSQL 数据库答案

【问题标题】：CQRS, Event Sourcing and NoSQL databaseCQRS、事件溯源和 NoSQL 数据库
【发布时间】：2012-04-17 21:00:38
【问题描述】：

我们正在启动一个新项目，希望在其中使用 MongoDB 实现 CQRS + 事件溯源架构。我们已经对 CQRS 方法有了一些经验：在我们之前的项目中，我们以 Fohjin 框架为起点（嗯，我们对其进行了重大重构）。在这种情况下，我们使用 Oracle 作为存储，并使用 TransactionScope 实现了 2PC。

但是对于我们的新项目，我们希望使用 MongoDB，因为它具有可扩展性和性能。我们肯定想将它用于读取（报告）部分并将其用于事件存储。此处的替代方法是使用 SQL Server 进行事件存储。所以我们需要做出选择。我不喜欢混合解决方案的是 TransactionScope，它既昂贵又缓慢，而且需要支持不同的 Db 类型（Mongo 和 SQL）。

我们研究了 NCQRS，但似乎我们不想高度依赖任何框架，从我们的角度来看，这决定了很多可以以不同方式实现的东西。所以现在我们正在考虑更轻量级的东西，比如 Jonathan Oliver 的 Event Store。我喜欢流和提交的概念，它也支持 MongoDB。我仍然不明白的是，它如何处理所有 2PC 的东西（据说是用于 NoSQL）。在我们的例子中，我们需要将事件分配给几个事件处理程序：某种类型的去噪器，它为特定类型的事件更新读取数据库和任务调度器。如果这些处理程序出现问题并且我们遇到异常，则无法回滚 MongoDB 的提交。有什么技巧可以解决这个问题吗？

我感谢任何关于如何做出正确决定以及利弊的问题。

【问题讨论】：

标签： .net mongodb cqrs

【解决方案1】：

EventStore 使用 Guid 来唯一标识针对数据库的提交，以防止相同的事件流被持久化多次。通常，此 Guid 直接嵌入在消息中，唯一标识该特定消息，并且可以在对事件流调用 CommitChanges 时用作 CommitId。在系统查询端处理事件时，您可以使用类似的方法。

更多关于 2PC 和避免分布式事务的信息：

【讨论】：

感谢您的回答，艾略特。据我了解，我需要使我的事件处理程序/管道挂钩是幂等的，添加某种过滤器来确定事件/提交已经被调度。这听起来像是为每个处理程序添加了很多额外的代码（嗯，也许它可以实现为方面或类似的东西）。 Busides，它为每个处理程序添加了一个新的数据库查询，以进行检查。但是，好吧，我们可以称之为“解决方案的成本”。另一个问题是何时处理部分处理的事件/提交？
是的，您需要构建基础架构以使您自己的事件处理程序具有幂等性。一种方法是在您的事件中嵌入一个唯一的 Id 并将此 Id 包含在您的读取模型中 - 然后您将能够判断您是否多次处理了一个事件。