我们正在启动一个新项目，希望使用 MongoDB 实现 CQRS + 事件源架构。我们已经对 CQRS 方法有了一些经验：在我们之前的项目中，我们以 Fohjin 框架为起点（嗯，我们对其进行了重大重构）。在这种情况下，我们使用 Oracle 作为存储，并使用 TransactionScope 实现了 2PC。
但对于我们的新项目，我们希望使用 MongoDB，因为它的可扩展性和性能。我们肯定想将它用于读取（报告）部分，并将其考虑用于事件存储。这里的替代方案是使用 SQL Server 进行事件存储。所以我们需要做出选择。我不喜欢混合解决方案的是 TransactionScope，它昂贵且缓慢，并且必须支持不同的数据库类型（Mongo 和 SQL）。
我们研究了 NCQRS，但似乎我们不想高度依赖任何框架，它规定了很多可以从我们的角度以不同方式实现的东西。所以现在我们正在考虑一些更轻量级的东西，比如 Jonathan Oliver 的 Event Store。我喜欢流和提交的概念，它还支持 MongoDB。我仍然不明白的是，它如何处理所有 2PC 的东西（据说是针对 NoSQL 的）。在我们的例子中，我们需要将事件分配给多个事件处理程序：某种为某些类型的事件更新读取数据库和任务调度程序的去分化器。如果这些处理程序出现问题并且我们收到异常，则无法回滚 MongoDB 的提交。有什么技巧可以处理这个问题吗？
我感谢任何关于如何做出正确决定以及利弊的评论。
小智 5
EventStore 使用 Guid 来唯一标识对数据库的提交，以防止同一事件流被多次持久化。通常，此 Guid 直接嵌入在消息中，唯一标识该特定消息，并且可以在对事件流调用 CommitChanges 时用作 CommitId。在处理系统查询端的事件时，您可以使用类似的方法。
有关 2PC 和避免分布式事务的更多信息：
| 归档时间： |
|
| 查看次数： |
2946 次 |
| 最近记录： |