一起进阶学习JAVA：分布式理论（一）

什么是分布式系统

分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。即将一个业务拆分成不同的几个子业务并分别部署再不同的服务节点，共同构成的系统。

分布式系统的特点

• 分布性：不同的子业务分布在不同的服务节点
• 对等性：分布式系统中的各个节点都包含自己的处理机和内存,各自具有独立的处理数据的功能
• 并发性：一个大的任务可以划分为若干个子任务,分别在不同的主机上执行
• 缺乏全局时钟：因为分布性的原因，系统分布在不同的服务节点，而各个服务节点都有自己独立的时钟
• 故障

分布式系统的问题

1. 通信异常
   由于网络本身的不可靠性导致每次网络通信都会伴随着不可用风险，最终会导致不同服务节点的分布式系统无法进行网络同学，并且网络通信具有延时性，这也会影响到消息收发过程中的消息延迟或者丢失
2. 网络分区
   网络之间出现了网络不连通，但是各个子网络之间的内部网络又是正常的，从而导致整个系统的网络环境被切分成了若干个独立的区域
3. 节点故障
   节点故障是分布式系统下比较常见的问题，节点故障指的是分布式系统的服务器节点发生宕机等现象
4. 三态
   分布式系统每一次请求与响应存在特有的“三态”概念，即成功、失败和超时。
   分布式系统中，由于网络是不可靠的，虽然绝大部分情况下，网络通信能够接收到成功或失败的响应，但当网络出现异常的情况下，就会出现超时现象，通常有以下两种情况：
   1）由于网络原因，该请求并没有被成功的发送到接收方，而是在发送过程就发生了丢失现象。
   2）该请求成功的被接收方接收后，并进行了处理，但在响应反馈给发送方过程中，发生了消息丢失现象。

分布式理论

一致性

分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的。

副本一致性

分布式系统当中，数据往往会有多个副本。如果是一台数据库处理所有的数据请求，那么通过ACID四原则，基本可以保证数据的一致性。而多个副本就需要保证数据会有多份拷贝。这就带来了同步的问题，因为我们几乎没有办法保证可以同时更新所有机器当中的包括备份所有数据。 网络延迟，即使我在同一时间给所有机器发送了更新数据的请求，也不能保证这些请求被响应的时间保持一致存在时间差，就会存在某些机器之间的数据不一致的情况。

一致性分类

强一致性

这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。但是强一致性很难实现。

弱一致性

这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。

• 读写一致性
  用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容。
  比如我们发一条朋友圈，朋友圈的内容是不是第一时间被朋友看见不重要，但是一定要显示在自己的列表上.

  解决方案:
  方案1：一种方案是对于一些特定的内容我们每次都去主库读取。 （问题主库压力大）
  方案2：我们设置一个更新时间窗口，在刚刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，我们会挑选最近有过更新的从库进行读取
  方案3：我们直接记录用户更新的时间戳，在请求的时候把这个时间戳带上，凡是最后更新时间小于这个时间戳的从库都不予以响应。
  

• 单调读一致性
  本次读到的数据不能比上次读到的旧。
  由于主从节点更新数据的时间不一致，导致用户在不停地刷新的时候，有时候能刷出来，再次刷新之后会发现数据不见
  了，再刷新又可能再刷出来，就好像遇见灵异事件一样

  解决方案:
  就是根据用户ID计算一个hash值，再通过hash值映射到机器。同一个用户不管怎么刷新，都只会被映射到同一台机器上。
  这样就保证了不会读到其他从库的内容，带来用户体验不好的影响。
  

• 因果一致性

  如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。

• 最终一致性

  最终一致性是所有分布式一致性模型当中最弱的。可以认为是没有任何优化的“最”弱一致性，它的意思是说，我不考虑所有的中间状态的影响，只保证当没有新的更新之后，经过一段时间之后，最终系统内所有副本的数据是正确的。它最大程度上保证了系统的并发能力，也因此，在高并发的场景下，它也是使用最广的一致性模型。
  

CAP定理

CAP 理论含义是，一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。

选项	描述
C 一致性	分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致
A 可用性	Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常
P 分区容错性	系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务

• C - Consistency

  一致性是值写操作后读操作可以读到最新的数据状态,当数据分布在多个节点上时,从任意节点读取到的数据都是最新的.

• A - Availability

  可用性是指任何操作都可以得到响应的结果,且不会出现响应超时或响应错误。

• P - Partition tolerance

  分布式系统的各个节点部署在不同的子网中, 不可避免的会出现由于网络问题导致节点之间通信失败,此时仍可以对外提供服务, 这个就是分区容错性 (分区容忍性).

CAP只能 3 选 2，假设有一个系统如下：

有用户向N1发送了请求更改了数据，将数据库从V0更新成了V1。由于网络断开，所以N2数据库依然是V0，
如果这个时候有一个请求发给了N2，但是N2并没有办法可以直接给出最新的结果V1，这个时候该怎么办呢？

这个时候无法两种方法，一种是将错就错，将错误的V0数据返回给用户。第二种是阻塞等待，等待网络通信恢复，N2中
的数据更新之后再返回给用户。显然前者牺牲了一致性，后者牺牲了可用性。

这个例子虽然简单，但是说明的内容却很重要。在分布式系统当中，CAP三个特性我们是无法同时满足的，必然要舍弃一
个。三者舍弃一个，显然排列组合一共有三种可能。

1. 舍弃A(可用性)，保留CP(一致性和分区容错性)

   一个系统保证了一致性和分区容错性，舍弃可用性。也就是说在极端情况下，允许出现系统无法访问的情况出现，这个时候往往会牺牲用户体验，让用户保持等待，一直到系统数据一致了之后，再恢复服务。

2. 舍弃C(一致性)，保留AP(可用性和分区容错性)

   这种是大部分的分布式系统的设计，保证高可用和分区容错，但是会牺牲一致性。

3. 舍弃P(分区容错性)，保留CA(一致性和可用性)

   如果要舍弃P，那么就是要舍弃分布式系统，CAP也就无从谈起了。可以说P是分布式系统的前提，所以这种情况是不存在的。

BASE 理论

BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。

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

• Basically Available(基本可用)
  基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。
• Soft state（软状态）
  允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。
• Eventually consistent（最终一致性）
  最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

一致性协议 2PC

2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Preparephase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。

2PC协议阶段过程

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

执行流程

• 成功执行事务事务提交流程
  

阶段一:

1. 事务询问协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2. 执行事务 (写本地的Undo/Redo日志)
3. 各参与者向协调者反馈事务询问的响应
   总结: 各个参与者进行投票是否让事务进行.

阶段二:

1. 发送提交请求：
   协调者向所有参与者发出 commit 请求。

2. 事务提交：
   参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。

3. 反馈事务提交结果：
   参与者在完成事务提交之后，向协调者发送 Ack 信息。

4. 完成事务：
   协调者接收到所有参与者反馈的 Ack 信息后，完成事务。

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

• 中断事务步骤如下：
  假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务
  

阶段一:

1. 事务询问
   协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2. 执行事务 (写本地的Undo/Redo日志)
3. 各参与者向协调者反馈事务询问的响应

总结: 各个参与者进行投票是否让事务进行.

阶段二:

1. 发送回滚请求：
   协调者向所有参与者发出 Rollback 请求。
2. 事务回滚：
   参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3. 反馈事务回滚结果：
   参与者在完成事务回滚之后，向协调者发送 Ack 信息。
4. 中断事务：
   协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。

从上面的逻辑可以看出，二阶段提交就做了2个事情：投票，执行。

2PC协议的优缺点

优点

原理简单，实现方便

缺点

• 同步阻塞：
  二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
• 单点问题：
  协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
• 数据不一致：
  假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有commit 请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
• 过于保守：
  如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。

3PC协议

3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。

阶段一：CanCommit

1. 事务询问
   协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2. 各参与者向协调者反馈事务询问的响应参与者在接收到来自协调者的包含了事务内容的canCommit请求后，正常情况下，如果自身认为可以顺利执行事务，则反馈Yes响应，并进入预备状态，否则反馈No响应。

阶段二：PreCommit

协调者在得到所有参与者的响应之后，会根据结果有2种执行操作的情况：执行事务预提交，或者中断事务假如所有参与反馈的都是Yes，那么就会执行事务预提交。

1. 发送预提交请求：
   协调者向所有参与者节点发出preCommit请求，并进入prepared阶段。
2. 事务预提交：
   参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
3. 各参与者向协调者反馈事务执行的结果：
   若参与者成功执行了事务操作，那么反馈Ack

若任一参与者反馈了No响应，或者在等待超时后，协调者尚无法接收到所有参与者反馈，则中断事务

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

阶段三：do Commit

该阶段做真正的事务提交或者完成事务回滚，所以就会出现两种情况：

• 执行事务提交

1. 发送提交请求：
   进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状态转化为提交状态，并向所有的参与者发送doCommit请求。
2. 事务提交：
   参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事务资源。
3. 反馈事务提交结果：
   参与者在完成事务提交后，向协调者发送Ack响应。
4. 完成事务：
   协调者接收到所有参与者反馈的Ack消息后，完成事务。

• 中断事务

1. 发送中断请求：协调者向所有的参与者节点发送abort请求。
2. 事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个事务执行期间占用的资源。
3. 反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息。
4. 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务。

注意：一旦进入阶段三，可能会出现 2 种故障：1. 协调者出现问题 2. 协调者和参与者之间的网络故障
如果出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交

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