我认为要实现高机能，可以谈的器械还有很多。下面我想重点说说我想到的一些设计思路：
避开资本争夺
秒杀晃荡的例子分析
我认为这是很重要的一点。什么是资本争夺？我想就是多个线程同时修改同一个数据。就像阿琅绫请杀晃荡一样，秒杀开抢时，很多人同时抢一个商品，导致商品的库存会被并发更新减库存，这就是一个资本争夺的例子。一般如不雅资本竞争不激烈，那无所谓，不会影响机能；然则如不雅像秒杀这种场景，那db就会抗不住了。在秒杀这种场景下，大年夜量线程须要同时更新同一笔记录，进而导致MySQL内部大年夜量线程聚积，对办事机能、稳定性造成很大年夜伤害。那怎么办呢？我记得阿里的丁奇写过一个分享，思路就是当MySQL的办事端多个线程同时修改一笔记录时，可以对这些修改请求进行列队，然后对于InnoDB引擎层，就是串行的。如许列队后，不管上层应用发过来若干并行的修改同一行的请求，对于MySQL Server妒攀来说，内部老是会聪慧的对同一行的修改请求都列队处理；如许就能确保不会有并发产生，大年夜而不会导致线程浪费聚积，导致数据库机能降低。这个筹划可以见下图所示：
如上图所示，当很多请求都要修改A记录时，MySQL Server内部会对这些请求进行列队，然后一个个将对A的修改请求提交到InnoDB引擎层。如许看似在列队，实际上会确保MySQL Server不会逝世掉落，可以包管对外供给稳定的TPS。
然则，对于商品秒杀这个场景，还有优化的空间，就是Group Commit技巧。Group Commit就是对多个请求归并为一次操作进行处理。秒杀时，大年夜家都在购买这个商品，A买2件，B买3件，C买1件；其实我们可以把A,B,C的┞封三个请求归并为一次减库存操作，就是一次性减6件。如许，对于A,B,C的┞封三个请求，在InnoDB层我们只须要做一次减库存操作即可。假设我们Group Commit的每一批的size是50，那就是可以将50个减操作归并为一次减操作，然后提交到InnoDB。如许，将大年夜大年夜进步秒杀场景下，商品减库存的TPS。然则这个Group Commit的每批大年夜小不是越大年夜越好，而是要根据并发量以及办事器的实际情况做测试来获得一个最优的值。经由过程Group Commit技巧，根据丁奇的PPT，商品减库存的TPS机能大年夜本来的1.5W进步到了8.5W。
大年夜膳绫擎这个例子，我们可以看到阿里是如安在实际场景中，经由过程优化MySQL Server来实现高并发的商品减库存的。然则，这个技巧一般人还真的不会！因为没若干人有才能却竽暌古化MySQL的办事端，列队也不可，更别说Group Commit了。这个功能并不是MySQL Server自带的，而是须要本身实现的。然则，这个思路我想我们都可以借鉴。
CQRS若何实现避免资本竞争
那么对于CQRS架构，若何按照这个思路来设计呢？我想重点说一下我膳绫擎提到的第二种CQRS架构。对于C端，我们的目标是尽可能的在1s内处理更多的Command，也就是数据写请求。在经典DDD的四层架构中，我们会有一个模式叫工作单位模式，即Unit of Work（简称UoW）模式。经由过程该模式，我们能在应用层，一次性以事务的方法将当前请求所涉及的多个对象的修改提交到DB。微软的EF实体框架的DbContext就是一个UoW模式的实现。这种做法的好处是，一个请求对多个聚合根的修改，能做到强一致性，因为是事务的。然则这种做法，实际上，没有很好的遵守避开资本竞争的原则。试想，事务A要修改a1,a2,a3三个聚合根；事务B要修改a2,a3,a4；事务C要修改a3,a4,a5三个聚合根。那如许，我们很轻易懂得，这三个事务只能串行履行，因为它们要修改雷同的资本。比如事务A和事务B都要修改a2,a3这两个聚合根，那同一时刻，只能由一个事务能被履行。同理，事务B和事务C也是一样。如不雅A,B,C这种事务履行的并发很高，那数据库就会出现严重的并发冲突，甚至逝世锁。那要若何避免这种资本竞争呢？我认为我们可以采取三个办法：
让一个Command老是只修改一个聚合根
这个做法其实就是缩小事务典范围，确保一个事务一次只涉及一笔记录的修改。也就是做到，只有单个聚合根的修改才是事务的，让聚合根成为数据强一致性的最小单位。如许我们就能最大年夜化的实现并行修改。然则你会问，然则我一个请求就是会涉及多个聚合根的修改的，这种情况怎么办呢？在CQRS架构中，有一个器械叫Saga。Saga是一种基于事宜驱动的思惟来实现营业流程的技巧，经由过程Saga，我们可以用最终一致性的方法最终实现对多个聚合根的修改。对于一次涉及多个聚合根修改的营业场景，一般老是可以设计为一个营业流程，也就是可以定义出要先做什么后做什么。比如以银行转账的场景为例子，如不雅是按照传统事务的做法，那可能是先开启一个事务，然后让A账号扣减余额，再让B账号加上余额，最后提交事务；如不雅A账号余额不足，则直接抛出异常，同理B账号如不雅加上余额也碰到异常，那业执ゴシ个异常即可，事务会包管原子性以及主动回滚。也就是说，数据一致性已经由DB帮我们做掉落了。
然则，如不雅是Saga的设计，那就不是如许了。我们会把全部转账过程定义为一个营业流程。然后，流程中会包含多个介入该流程的聚合根以及一个用于调和聚合根交互的流程治理器（ProcessManager，无状况），流程治理器负责响应流程中的每个聚合根产生的范畴事宜，然后根据事宜发送响应的Command，大年夜而持续驱动其他的聚合根进行操作。
转账的例子，涉及到的聚合根有：两个银行账号聚合根，一个交易（Transaction）聚合根，它用于负粜ユ储流程的当缁ご态，它还会保护流程状况变革时的规矩束缚；然后当然还有一个流程治理器。转账开端时，我们会先创建一个Transaction聚合根，然后它产生一个TransactionStarted的事宜，然河道程治理器响应事宜，然后发送一个Command让A账号聚合根做减余额的操作；A账号操作完成后，产生范畴事宜；然河道程治理器响应事宜，然后发送一个Command通知Transaction聚合根确认A账号的操作；确认完成后也会产闹事宜，然河道程治理器再响应，然后发送一个Command通知B账号做加上余额的操作；后续的步调就不具体讲了。大年夜概意思我想已经表达了。总之，经由过程如许的设计，我们可以经由过程事宜驱动的方法，来完成全部营业流程。如不雅流程中的任何一步出现了异常，那我们可以在流程中定义补偿机制实现回退操作。或者不回退也没紧要，因为Transaction聚合根记录了流程的当缁ご态，如许我们可以很便利的后续排查有状况没有正常停止的转账交易。具体的设计和代码，有兴趣的可以去看一下ENode源代码中的银行转账的例子，琅绫擎有完全的实现。
推荐阅读
因为这些技巧的合营之处是它们生成本身的特点，也许我们应当称之为无特点建模的阶段（Era of Featureless Modeling）。你仍然不得不应用已知的标注实例进行练习，然则你不必在列中填入预定>>>详细阅读
本文标题：谈一下关于CQRS架构如何实现高性能
地址：http://www.17bianji.com/lsqh/36039.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示