分布式理论分析

分布式系统特点：

1. 分布性
2. 对等性：每个机器都是一样的级别，没有主从之分
3. 并发性：同时访问一个节点
4. 缺乏全局时钟：各个服务器时间不统一
5. 故障总会发生

分布式系统面临问题：

1. 通信异常
2. 网络分区
3. 节点故障：
4. 三态：分布式系统每一次请求与相应存在特有的三态，即成功，失败和超时。三态中超时的情况：
   1. 客户端发送请求服务器失败
   2. 服务端处理成功无法响应给用户

一致性分类

1. 强一致性：加锁

2. 弱一致性：

   1. 读写一致性：
      1. 加时间戳，大于该时间戳查响应
      2. 读主库
      3. 设置更新窗口时间，在该时间内进行查询读取主库，写定时在过段时间设置成读取从库
   2. 单调读一致性：每次读取的数据可能出现比上次旧的数据，解决方式是根据用户ID计算一个hash值，再通过hash值映射到机器上，同一个用户不管怎么刷新，都只会映射到同一台机器上
   3. 因果一致性：节点A每次更新完要通知B，那么B节点之后数据的访问和修改都是基于A更新后的值。而节点C和A没有因果关系，则不会出现这样的限制。
   4. 最终一致性：该一致性是分布式系统中最弱的。

CAP定理：C一致性，A可用性，P分区容错性。三者中只能满足其中两个。

1. C：整个系统中一个节点数据变更，所有节点都变更，保证数据一直

2. A：系统一直对外提供服务，不能中断

3. P：在分布式基础上提出，不管某个节点网络出现异常或者宕机都要对外界提供可持续的服务

舍弃C，会导致用户的数据不一致现象

舍弃A，则会出现用户访问不通

舍弃P，就不是分布式，是单点

BASE理论：一致性和可用性之间进行协调。也就是BASE是对CAP的协调。

1. BA基本可用：（值分布式系统出现不可预知故障的时候，允许损失部门可用性，但不是系统不可用）

   1. 系统响应时间上的损失：响应时间变长，比如12306出现的抢票失败
   2. 功能上的损失：比如提交订单报错，过段时间又可以支付。

2. Softstate软状态：允许系统中的数据存在中间状态。支付中这个状态就是软状态，或者比如配送中

3. E最终一致性：经过软状态之后，最终达到一定状态。

BASE理论的核心思想：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

一致性协议2PC：两阶段提交协议，是将整个事务分为两个阶段，P为准备阶段，C为回滚阶段。

用来解决分布式事务

oracle、mysql支持该协议

1. 准备阶段(确认阶段)：事务管理器给每一个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志。此时事务没有提交。（Undo是记录修改前的数据，用于数据库回滚。Redo日志是记录修改后的数据，用于提交事务后写入数据文件）
2. 提交/回滚阶段：事务管理器收到参与者的执行失败或者超时的Prepare消息时，直接给每个参与者发送回滚（RoolBack）消息。否则，发送提交消息。参与者根据事务事务管理器的指令执行提交或者回滚操作。并释放事务处理过程中使用的锁资源。注意，必须在最后阶段释放锁资源。

2PC执行流程：

1. 成功提交事务：参与者1和2都给协调者返回Yes之后，协调者会发送Commit请求给各个参与者，二者均发送 ACK给协调者证明请求收到并执行成功。

ACK是 确认字符，在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。

2. 中断事务：当协调者给各个参与者发送Prepare请求，有的返回No或者没有返回时，协调者会发送RollBack请求 让参与者进行回滚，然后执行undo日志进行回滚，并返回ACK。

   

优点：

1. 原理简单/实现方便

缺点：

1. 同步阻塞（所有节点全部完成任务才能发第二次请求，这样就出现阻塞。）
2. 单点问题（协调者出现问题，所有参与者都出现锁定状态，单一）
3. 数据不一致（资源一执行完了，但是协调者还没有给资源二发送请求就宕机，导致各个资源数据不一致）
4. 数据不一致，过于保守（某一个节点出现问题，全部变成超时，事务全部回滚）

一致性协议3PC：

1. CanCommit，（事务询问）

   1. 由协调者发送一个包含事务的请求给所有参与者，询问参与者是否有能力执行事务提交操作。并开始等待各个参与者的响应。
   2. 各参与者向协调者反馈响应。参与者在接收到来自协调者包含了事务内容的CanCommit请求后，如果自身可以顺利执行事务，返回Yes并进行第二阶段（预备阶段），返回No则异常中断。

2. PreCommit（事务预请求阶段或者中断事务阶段）

   1. 所有参与者都返回YES，

      1. 协调者向所有参与者发送preCommit预提交请求，进入prepared准备阶段。
      2. 参与者接收到preCommit请求，会执行事务，并将undo（执行之前的日志）和redo（记录操作之后的日志消息）一些日志
      3. 并且所有参与者向协调者返回ACK（消息字符序列）

   2. 有参与者返回NO或者等待超时后协调者无法接收所有参与者的反馈，则事务中断：

      1. 发送中断请求，协调者向所有参与者发出abort请求。
      2. 中断事务：无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务。

3. do Commit（事务提交）

   1. 正常情况：协调者发送doCommit给所有参与者，参与者对自己的事务进行提交，返回YES给协调者，事务结束。
   2. 事务中断情况：协调者把abort请求发送给所有参与者，参与者执行回滚操作。回滚操作执行后也会把YES操作返回给协调者，结束。

协调者挂掉或者协调者/参与者出现网络故障：参与者因为接收不到协调者的消息，事务就会自动提交。

2PC和3PC对比:

3PC协议并没有完全解决数据一致问题

1. 3PC对协调者和参与者都设置了超时机制（在2PC中只有协调者才有超时机制，如果一段时间内没有收到参与者的消息，协调者默认失败）。3PC之所以给协调者和参与者都设置了超时时间，主要是避免参与者在长时间无法与协调者节点通讯（协调者挂掉）的情况下，无法释放资源的问题。3PC出现参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行资源释放，因为也会降低整个事务的阻塞时间和范围。

2. 3PC添加了一个PreCommit缓冲阶段，可以更大的去保证最后提交阶段各参与节点状态一致