我对分布式的理解最基础层面是在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的独享免费版).
这种分布式的理论说明,在分布式条件下,没有绝对强一致或者高可用或容错性超强的设计,只能从三种模式中选其二.
