分布式系统CAP理论 / 分布式事务一致性

CAP理论：一个分布式系统最多只能同时知足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

Consistency 一致性（涉及重要信息如钱财；分布式存储系统必须保证）

从客户端角度，多进程并发访问时，更新过的数据在不一样进程如何获取的不一样策略，决定了不一样的一致性:

1.强一致性:对于关系型数据库，要求更新过的数据能被后续的访问都能看到.

2.弱一致性：能容忍后续的部分或者所有访问不到。

3.最终一致性：通过一段时间后要求能访问到更新后的数据。

CAP中说，不可能同时知足的这个一致性指的是强一致性。

Availability 可用性（大型互联网为了服务可用，舍弃强一致性，保证最终一致性）

服务一直可用，并且是正常响应时间。

可用性分类	可用水平（%）	年可容忍停机时间
容错可用性	99.9999	<1 min
极高可用性	99.999	<5 min
具备故障自动恢复能力的可用性	99.99	<53 min
高可用性	99.9	<8.8h
商品可用性	99	<43.8 min

Partition Tolerance分区容错性(分布式必需要考虑的问题）

分布式系统在遇到某节点或网络故障的时候，仍然可以对外提供知足一致性和可用性的服务。就是在网络中断的状况下，系统若是还能正常工做。

做为一个分布式系统，它和单机系统的最大区别，就在于网络.

如今假设一种极端状况，N1和N2之间的网络断开了:

假设N1和N2之间网络断开，因为网络是断开的，因此N2中的数据依旧是V0.

这时有用户向N2发送数据读取请求，

第一，牺牲数据一致性，保证可用性。响应旧的数据V0给用户；

第二，牺牲可用性，保证数据一致性。阻塞等待，直到网络链接恢复，数据更新操做M完成以后，再给用户响应最新的数据V1。

CA(一致性+可用性）without P（容错性）

    单机的Mysql和Oracle；

    分布式集群中不存在这种状况，由于多个节点一定考虑主备同步，也就是网络。

CP(一致性+容错性）without A（可用性）

    分布式的数据库，如Redis，HBase，Zookeeper

    任什么时候刻对ZooKeeper请求能获得一致的数据结果:当master节点网络故障，会进行选举机制，选举时集群不可用。可是它不能保证每次服务请求的可用性，ZooKeeper可能会丢弃一些请求，消费者程序须要从新请求才能得到结果。

AP(可用性+容错性）without C（一致性）

    12306买票

    购买的时候提示你是有票的（可是可能实际已经没票了），可是过了一会系统提示你下单失败，余票不足。其实舍弃的只是强一致性。退而求其次保证了最终一致性。

    Eureka

    各个节点平等；有节点挂掉，会马上换至其余节点，保证服务可用，只不过查到的信息可能不是最新的。在网络稳定后，当前实例新的注册信息会被同步到其余节点中。

一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，须要在用户访问时能够立刻获得返回，致使全局数据的不一致性。

分布式一致性

分布式事务：指会涉及到操做多个数据库的事务。

    关键在于保证在全部节点的数据写操做，要不所有都执行，要么所有的都不执行。可是一台机器在执行本地事务的时候没法知道其余机器中的本地事务的执行结果。因此也就不知道本次事务到底应该commit仍是 roolback。

    常规的解决办法就是引入一个“协调者”的组件来统一调度全部分布式节点的执行。

分布式事务处理模型：

    应用程序（ AP ）、

    事务管理器（ TM ）、常见的事务管理器是交易中间件

    资源管理器（ RM ）、常见的资源管理器是数据库

    通讯资源管理器（ CRM ）常见的通讯资源管理器是消息中间件

2PC(二阶段提交）

    参与者（全部节点RM）将操做成败通知协调者(事务管理器TM)，再由协调者根据全部参与者的反馈情报决定各参与者是否要提交操做仍是停止操做。

第一阶段：准备阶段(投票阶段)

    事务协调者(事务管理器)给每一个参与者(资源管理器)发送Prepare消息，每一个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，但不提交。

第二阶段：提交阶段（执行阶段）

    若是协调者收到了参与者的失败消息或者超时，直接给每一个参与者发送回滚(Rollback)消息；不然，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操做，释放全部事务处理过程当中使用的锁资源。

存在的问题：

    一、同步阻塞问题。执行过程当中，全部参与节点都是事务阻塞型的。当参与者占有公共资源时，其余第三方节点访问公共资源不得不处于阻塞状态。

    二、单点故障。因为协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤为在第二阶段，协调者发生故障，那么全部的参与者还都处于锁定事务资源的状态中，而没法继续完成事务操做。（若是是协调者挂掉，能够从新选举一个协调者，可是没法解决由于协调者宕机致使的参与者处于阻塞状态的问题）

    三、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求以后，发生了局部网络异常或者在发送commit请求过程当中协调者发生了故障，这回致使只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求以后就会执行commit操做。可是其余部分未接到commit请求的机器则没法执行事务提交。因而整个分布式系统便出现了数据部一致性的现象。

    四、二阶段没法解决的问题：协调者再发出commit消息以后宕机，而惟一接收到这条消息的参与者同时也宕机了。那么即便协调者经过选举协议产生了新的协调者，这条事务的状态也是不肯定的，没人知道事务是否被已经提交。

3PC(三阶段提交）

一、引入超时机制。同时在协调者和参与者中都引入超时机制。 

二、把准备阶段一分为二，最终：canCommit,preCommit,DoCommit。

解决：1.单点故障问题，2.减小阻塞。

    一旦参与者没法及时收到来自协调者的信息以后，会默认执行commit，而不会一直持有事务资源并处于阻塞状态。

存在问题：一致性问题。

    因为网络缘由，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时以后执行了commit操做。这样就和其余接到abort命令并执行回滚的参与者之间存在数据不一致的状况。