CQRS vs CRUD

关于一些名词

CQRS

Event Sourcing pattern

Materialized View pattern

一、CRUD有什么不好的地方

我们一般的开发是增删改查，写在一个项目里，写一个Model，也就是entity,里面有各种表的field,查和改的时候我们一般用同一个model，框架可能用hibernate,mybatis等。

但是同一个Model，可能会造成一些问题，比如你插入的数据，和你要查询的数据不匹配，比如查的数据用不着那么多列，这就造成了我们更新或者查询了一些额外的数据，造成性能的问题。

当然你可以说，我不同的更新或者查询创建不同的Model，来减少额外的查询。

但是还有个问题，当并发量多的时候，各种更新、查询都在这数据库里，会造成一些锁，性能上的影响，对数据库层是压力

还有一个是写的sql越来越复杂，表越来越多，级联越来越多，相信很多人会有同样的体会。

二、CQRS

这个时候就可以用CQRS了，简单的说就是数据的更新和查询用不同的接口。这里你可以理解为用不同的项目，查询我写在查询项目里，更新我写在更新的项目里。有同学会问，那我更新项目的时候如果想查询一些值呢？比如查询用户密码？

对了这时候就涉及到服务之间的调用了。现在你可以把查询、更新项目理解为两个服务，提供不同的角色、服务，也就是提供不同的接口，先不要想具体实现。

当然了，既然项目都拆开了，为了优化性能，我们可以吧数据库分开，一个用来写、一个用来查。

三、更新数据库的性能问题和数据不一致

虽然读写我们拆开了，但是写也会有各种性能问题，

但是这有产生出另一个问题，数据不一致性。

比如你更新了一个数据，而另一个数据库没有更新，可能有些地方出了问题。

这个时候我们就要用到event sourcing了，他可以把每个动作先保留下来，然后一个一个执行，这样并发问题解决了，而且保留的动作我们还可以让他去更新读数据库，来避免数据不一致。

具体的介绍可以看看这些

概念介绍

https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs

https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

https://docs.microsoft.com/en-us/azure/architecture/patterns/materialized-view

相关框架

https://doc.akka.io/docs/akka/2.5.4/scala/persistence.html

http://eventuate.io/docs/concepts.html

https://eventstore.org/

event sourcing框架比较

https://stackoverflow.com/questions/19467084/eventstore-vs-mongodb/25171917#25171917

cqrs推荐的一些技术框架

https://stackoverflow.com/questions/17708489/using-kafka-as-a-cqrs-eventstore-good-idea/47370656#47370656