CAP

CAP又叫Brewer理论，描述的是在一个分布式系统（主从架构）中涉及到共享数据的问题时，一致性，可用性和分区容错性，最多只能满足两个

• 一致性（Consistency）
  代表在任何时刻，任何分布式节点中，我们看到的数据都是没有矛盾的，与ACID中的C是相同的单词，但他们有不同的定义（分别指Replication的一致性和数据库状态的一致性），分布式事务中，ACID的C要以满足CAP中的C为前提，
• 可用性（Availability）
  代表系统不断的提供服务的能力
• 分区容错性（Partition Tolerance）
  代表分布式环境中，当部分节点因网络原因彼此失联（形成网络分区）时，系统仍能正确的提供服务能力
  CAP是忽略网络延迟的，当事务提交时，数据能够瞬间复制到所有节点，但是实际情况下总会有延迟，所以CAP中C在实践过程中是不可能完美的实现的，在复制过程中节点A和B的数据并不一致
  比如，分布式系统中有账号系统（管理用户余额），商家系统（存储订单），仓库系统（扣减库存）
  1.如果账号借点钱一扣减了100元，没有通知其他账号节点则会显示余额不对，此为一致性问题
  2.如果为了一致性，将修改同步给其他数据节点才可用，则为可用性问题
  3.由于北京和广州区通信异常就会导致，北京和广州获取的用户信息不一致，哪边操作都会影响集群的正确性，此为分区容忍性问题

CA架构应用

主流的RDBMS系统就是采用放弃分区容错性的工作模式，共享一份数据文件和控制文件，读写使用同一个数据节点，如果作分布式通过业务维度来区分，如，尾号为1，读写走Node1，尾号为2走Node2等

CP架构应用

HBase和ZK都属于CP架构，HBase中某个RegionServer节点挂机后所有的键值范围都将离线，知道数据恢复完成

AP架构应用

Redis就是AP架构，Eureka注册中心等

ACID和CAP中一致性为强一致性，把牺牲了C的AP系统，又要尽可能获取正确行为称为弱一致性，在弱一致性中又总结出一种特例叫做最终一致性

最终一致性的概念由eBay的系统架构师，发表论文提出，文章中总结了一种独立与ACID获得强一致性之外的途径，即通过BASE来达成最终一致性，最终一致性就是‘E’
通过支持事务的消息框架来实现分布式事务

BASE理论的内容

• 基本可用（Basically Available）
• 软状态（Soft State）
• 最终一致性（Eventually Consistent）