关于一些名词
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