CQRS、事件源和NoSQL数据库

Question

我们正在开始一个新的项目，我们想要用MongoDB实现CQRS +事件源架构。我们已经有了一些使用CQRS方法的经验:在我们之前的项目中，我们以Fohjin框架为起点(嗯，我们对其进行了重大重构)。我们使用Oracle作为存储，在这种情况下还使用TransactionScope实现了一个2PC。

但对于我们的新项目，由于其可伸缩性和性能，我们希望使用MongoDB。我们肯定想把它用于读取(报告)部分，并考虑将其用于事件存储。这里的替代方案是使用SQL Server进行事件存储。所以我们需要做出选择。我不喜欢混合解决方案的是TransactionScope，它既昂贵又慢，而且必须支持不同的数据库类型(Mongo和SQL)。

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

我很感谢任何关于如何做出正确的决定以及什么是利弊的评论。

Answer 1

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

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

• http://blog.jonathanoliver.com/2010/04/extending-nservicebus-avoiding-two-phase-commits
• http://blog.jonathanoliver.com/2011/04/how-i-avoid-two-phase-commit
• https://github.com/elliotritchie/NES/wiki/Transactions
• http://bill-poole.blogspot.com/2008/06/idempotent-messages.html