传统架构一次数据修改的步调是：1）大年夜DB掏出数据到内存；2）内存修改数据；3）更新数据回DB。总共涉及到2次数据库IO。
而在CQRS架构下，因为CQRS架构把读和写分别了，所以可用性相当于被隔离在了两个部分去推敲。我们只须要推敲C端若何解决写的可用性，Q端若何解决读的可用性即可。C端解决可用性，我认为是加倍轻易的，因为C端是消息驱动的。我们要做任何数据修改时，都邑发送Command到分布式消息队列，然后后端花费者处理Command->产生范畴事宜->持久化事宜->宣布事宜到分布式消息队列->最后事宜被Q端花费。这个链路是消息驱动的。比拟传统架构的直接办事办法调用，可用性要高很多。因为就算我们处理Command的后端花费者临时挂了，也不会影响前端Controller发送Command，Controller依然可用。大年夜这个角度来说，CQRS架构在数据修改上可用性要更高。不过你可能会说，如果分布式消息队列挂了呢？呵呵，对，这确切也是有可能的。然则一般分布式消息队列属于中心件，一般中心件都具有很高的可用性（支撑集群和主备切换），所以比拟我们的应用来说，可用性要高很多。别的，因为敕令是先发送到分布式消息队列，如许就能充分应用分布式消息队列的优势：异步化、拉模式、削峰填谷、基于队列的程度扩大。这些特点可以包管即便前端Controller在岑岭时刹时发送大年夜量的Command过来，也不会导致后端处理Command的应用挂掉落，因为我们是根据本身的花费才能拉取Command。这点也是CQRS C端在可用性方面的优势，其实本质也是分布式消息队列带来的优势。所以，大年夜这里我们可以领会到EDA架构（事宜驱动架构）是异常有价值的，这个架构也表现了我们今朝比较风行的Reactive Programming（响应式编程）的思惟。
然后，对于Q端，应当说和传统架构没什么差别，因为都是要处理高并发的萌芽。这点以前怎么竽暌古化的，如今照样怎么竽暌古化。然则就像我膳绫擎可扩大性里强调的，CQRS架构可以更便利的供给更多的View存储，数据库、缓存、搜刮引擎、NoSQL，并且这些存储的更新完全可以并行进行，互相不会拖累。幻想的场景，我认为应当是，如不雅你的应用要实现全文索引这种复杂萌芽，那可以在Q端应用搜刮引擎，比如ElasticSearch；如不雅你的萌芽场景可以经由过程keyvalue这种数据构造知足，那我们可以在Q端应用Redis这种NoSql分布式缓存。总之，我认为CQRS架构，我们解决萌询问题会比传统架构加倍轻易，因为我们选择更多了。然则你可能会说，我的场景只能用关系型数据库解决，且萌芽的并发也是异常高。那没办法了，独一的办法就是分散萌芽IO，我们对数据库做分库分表，以及对数据库做一主多备，萌芽走备机。这点上，解决思路就是和传统架构一样了。
机能、伸缩性
本来想把机能和伸缩性分开写的，然则想想这两个其实有必定的接洽关系，所以决定放在一路写。
伸缩性的意思是，当一个体系，在100人拜访时，机能（吞吐量、响应时光）很不错，在100W人拜访时机能也同样不错，这就是伸缩性。100人拜访和100W人拜访，对体系的压力显然是不合的。如不雅我们的体系，在架构上，可以或许做到经由过程简单的增长机械，就能进步体系的办事才能，那我们就可以嗣魅这种架构的伸缩性很强。那我们来想想传统架构和CQRS架构在机能和伸缩性膳绫擎的表示。
说到机能，大年夜家一般会先思虑一个体系的机能瓶颈在哪里。只要我们解决了机能瓶颈，那体系就意味着具有经由过程程度扩大来达到可伸缩的目标了（当然这琅绫腔有推敲数据存储的程度扩大）。所以，我们只要分析一下传统架构和CQRS架构的瓶颈点在哪里即可。
传统架构，瓶颈平日在底层数据库。然后我们一般的做法是，对于读：平日应用缓存就可以解决大年夜部分萌询问题；对于写：办法也有很多，比如分库分表，或者应用NoSQL，等等。比如阿里大年夜量采取分库分表的筹划，并且将来竽暌功该会全部应用高大年夜上的OceanBase来替代分库分表的筹划。经由过程分库分表，本来一台数据库办事度量岭时可能要遭受10W的高并发写，如不雅我们把数据放到十台数据库办事器上，那每台机械只须要承担1W的写，相对于要遭受10W的写，如今写1W就显得轻松很多了。所以，应当说数据存储对传统架构来说，也早已不再是瓶颈了。
然后CQRS架构，CQ两端加起来所用的时光肯定比传统架构要多，因为CQRS架构最多有3次数据库IO，1）持久化敕令；2）持久化事宜；3）根据事宜更新读库。为什么说最多？因为持久化敕令这一步不是必须的，有一种场景是不须要持久化敕令的。CQRS架构中持久化敕令的目标是为了做幂等处理，即我们要防止同一个敕令被处理两次。那哪一种场景下可以不须要持久化敕令呢？就是当敕令时在创建聚合根时，可以不须要持久化敕令，因为创建聚合根所产生的事宜的版本号老是为1，所以我们在持久化事宜时根据事宜版本号就能检测到这种反复。
所以，我们说，你要用CQRS架构，就必须要接收CQ数据的最终一致性，因为如不雅你以读库的更新完成为操作处理完成的话，那一次营业场景所用的时光很可能比传统架构要多。然则，如不雅我们以C端的处理为停止的话，则CQRS架构可能要快，因为C端可能只须要一次数据库IO。我认为这里有一点很重要，对于CQRS架构，我们加倍存眷C端处理完成所用的时光；而Q端的处理稍微慢一点没紧要，因为Q端只是供我们查看数据用的（最终一致性）。我们选择CQRS架构，就必须要接收Q端数据更新有一点灯揭捉?迟的缺点，不然就不该该应用这种架构。所以，欲望大年夜家在根据你的营业场景做架构选型时必定要充分熟悉到这一点。
可用性，无论是传统架构照样CQRS架构，都可以做到高可用，只要我们做到让我们的体系中每个节点都无单点即可。然则，比拟之下，我认为CQRS架构在可用性方面，我们可以有更多的躲避余地和选择空间。
别的，膳绫擎再谈到数据一致性时提到，传统架构会应用事务来包管数据的强一致性；如不雅事务越复杂，那一次事务锁的表就越多，锁是体系伸缩性的大年夜敌；而CQRS架构，一个敕令只会修改一个聚合根，如不雅要修改多个聚合根，则经由过程Saga来实现。大年夜而绕过了复杂事务的问题，经由过程最终一致性的思路做到了最大年夜的并行和起码的并发，大年夜而整体上进步体系的吞吐才能。
推荐阅读
一、懂得框架解决了什愦问题不管对于那个段位的 Developer 来说，读源码都是一件好处颇多的工作，特别于初学者而言，这能敏捷的吸纳优良框架精华代码养分，敏捷成长。不巧的是，晦涩难解的>>>详细阅读
地址：http://www.17bianji.com/lsqh/36067.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示