https://www.cnblogs.com/wzh2010/p/15311142.html 原文链接
我对分布式的理解最基础层面是在dubbo zookeeper , springcloud上的.
但是出发点和引发我的思考的并不是这些微服务框架,
而是基于mybatisplus中的版本号@Version.
因为在mybatisplus之中有@Version注解用于解决多客户端修改同数据的事务问题,(但此时还没到分布式事务)
使用这个注解可以得到解决,其原理之前的笔记或博客已经也记录过了.
而分布式中的事务可能就牵扯道要用redis做一个version的处理了,毕竟可能牵扯到的表可能不在一个服务器中,
但是又要进行同步操作.
CA: 放弃分区容错性。非分布式架构，比如关系数据库，因为没有分区，但是在分布式系统下，CA组合就不建议了。
AP: 放弃强一致性。追求最终一致性，类似的场景比如转账，可以接受两小时后到账，Eureka的注册也是类似的做法。
CP: 放弃可用性。zookeeper在leader宕机后，选举期间是不提供服务的。类似的场景比如支付完成之后出订单，必须一进一出都完成才行。
Brand这里说的CAP,即CAP理论.
C:Consistency
A:Avaliability
P:Partition Tolerance
这张图中实现CP的(一致性+分区容错性)的有MongoDB,HBase,Redis这种非关系型数据库
实现AP理论(可用性,分区容错性)的有CouchDB,Cassandra,DynamoDB.
实现CA理论(一致性+可用性)的有关系型数据库如SQL Server,MySQL,MariaDB(mysql的独享免费版).
这种分布式的理论说明,在分布式条件下,没有绝对强一致或者高可用或容错性超强的设计,只能从三种模式中选其二.
可以看到，对于分布式没有完美的解决方案，而只能从三中选二。就像你只能有一个老婆，而不能是变成我的前偶像王力宏，成为法外狂徒！（我恨他）
当我在想，在看非Brand的博客了解分布式时，其中有二阶段提交，而在其中也提到了“协调者”，我不太清楚这个协调者具体的作用，
是类似站岗的人员，指挥外来的外卖人员在指定地点送外卖，外来车辆依次停好车，外来人员预先进行登记这种事情吗？如果是，
我就非常明白了，因为我也站岗过，对这种事情驾轻就熟。
好，能看到图片的有福了，真实帅哥（想想其实也没我帅好吧感觉确实这个挺帅）。就想象他来指挥车辆和人员吧。
再来一张别的，总之，这些帅哥，就是协调者。秩序维护协调者。
而在分布式事务，例如二，或三阶段提交，都有一个预制的过程，并不能说，这个外卖员想进公司大楼就进，外来车辆想随便停车就能停，
外来人员想进去找谁就找谁，That isn't right， so，make a plan，through the 2pc / 2pc let the transaction knowing who and what will give the database a update pouch.
如上图，
首先站岗人员对两个进入的车辆进行指挥，不能进行交叉停车，阻挡了道路（以至于后来的请求都堵住了）
即执行了prepare阶段，站岗人员对着两个操作者说“每人一个车位，按先到者先停，进行停车”，之后两辆车则各自停好了。
当然这个停车场，就属于一个数据库，没有分布式处理，即完全对应了@Version版本号到那一套。
比如来了两辆车，站岗人员一看，就还有一个车位，则按优先到达处理原则（跟客户端先请求到处理一致）进行车位的安排停车，另一辆车，
只好告诉他，车位已满（虽然你们也算是同一时间来的，但是按照队列处理后，*（毕竟不可能让汽车并驾齐驱地向停车位驶去，导致站岗人员不知道该指挥谁先停车（线程抢占阻塞））
那怎么办呢，像大量的用户请求，不管是阿里的秒杀还是微信的红包，总会有一个先后顺序的，不管是令牌桶处理还是其它的处理方式，（那些之后更新-配合更新到消息队列学习），对吧，起码还是要有顺序的，不然就会出现超卖啊，余额为负的bug！～
站岗人员还是要进行一辆车一辆车的指挥，毕竟在入口处，还是仅有车身宽度的地方驶入停车场的，如果两辆车能挤在一起通过，是不可能的，否则世界会变成二次元了。
好，看完了小汽车，相信在注视着屏幕的你也明白了，先来后到的道理。（很多的丛林原则和社会原则也是基于此的）
但是分布式的停车场（数据库）该怎样进行车辆（数据）的安排（更新）呢？
假设刚才的停车位在大楼的左侧，而实际上在大楼的右侧还有一处停车的位置，两个停车的区域距离较远，一个区域的停车是内部员工用的，另一区域是外部人员拜访临时停车用的。（就假设Brand提到的订单数据看，库存数据库的售卖操作， 亦或是 何同学银行账户&野生钢铁侠同学银行账户的转账操作）
那么当协调者（就是刚上传的那些帅哥）去进行不同人员车辆的安排时，这里写死一个场景，是说车辆都是一辆内部车辆+一辆外部车辆这么来的，
那么每次协调者都将进行车辆的合理停车安排。处理完成后，数据将进行更新（内部人员+外部人员对公司的合理拜访业务完成），并更新同步到两个车位（库表）中。
当然在这之前要进行登记等一些prepared操作，比如三阶段提交
prepare ，pre-commit ，commit
这里可以想象一下，内部销售人员带着外部人员来购买公司等软件。
需要通过帅哥安排车位，并通过帅哥进行了登记（登记本）prepare，身份核实（通知单位是否有这个业务这两位人员）pre-commit，最终确认通过放行允许进行他们进入公司促成他们的软件销售业务commit。