.net – CQRS,事件采购和NoSQL数据库

发布时间：2020-12-13 13:28:26 所属栏目：百科来源：网络整理

导读：我们正在开始一个新项目,我们希望用MongoDB实现CQRS事件采购架构.我们已经有了一些CQRS方法的经验：在我们之前的项目中,我们将Fohjin框架作为一个起点(好吧,我们对它进行了重大的重构).在这种情况下,我们使用Oracle作为存储,并使用TransactionScope实现了2PC

我们正在开始一个新项目,我们希望用MongoDB实现CQRS事件采购架构.我们已经有了一些CQRS方法的经验：在我们之前的项目中,我们将Fohjin框架作为一个起点(好吧,我们对它进行了重大的重构).在这种情况下,我们使用Oracle作为存储,并使用TransactionScope实现了2PC.

但是对于我们的新项目,由于其可扩展性和性能,我们希望使用MongoDB.我们肯定希望将它用于读取(报告)部分并将其用于事件存储.这里的替代方法是使用SQL Server进行事件存储.所以我们需要做出选择.我不喜欢混合解决方案的是TransactionScope,它既昂贵又慢又需要支持不同的Db类型(Mongo和SQL).

我们查看了NCQRS,但似乎我们不希望高度依赖任何框架,这些框架规定了许多可以从我们的观点不同地实现的事情.所以现在我们正在考虑像Jonathan Oliver的Event Store那样更轻量级的东西.我喜欢流和提交的概念,它也支持MongoDB.我仍然不明白,它如何处理所有2PC的东西(据说,对于NoSQL来说).在我们的例子中,我们需要将事件dipatch到几个事件处理程序：某种denomalizer更新读取数据库和任务sheduler用于某些类型的事件.如果这些处理程序出现问题并且我们得到了一个exeption,则无法回滚MongoDB的提交.有没有办法解决这个问题？

我感谢任何关于如何做出正确决定以及利弊的评论.

解决方法

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!