分布式一致性

2019-01-29

1 概述

  • 集中式系统： 一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。
  • 分布式系统： 一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统，一群独立计算机集合共同对外提供服务。

分布式领域CAP理论告诉我们，任何一个分布式系统都无法同时满足Consistency(一致性),Availability(可用性), Partition tolerance(分区容错性) 这三个基本需求。但是，一个分布式系统无论在CAP三者之间如何权衡，都无法彻底放弃一致性(Consistency)。这里的分布式一致性问题通常指的是数据一致性问题。

关于分布式的详细介绍可以参看Interview-Notebook —— 分布式

2 一致性模型

  • 强一致性：新的数据一旦写入，在任意副本任意时刻都能读到新值。
  • 弱一致性：当你写入一个新值后，读操作在数据副本上可能读出来，也可能读不出来。
  • 最终一致性：当你写入一个新值后，有可能读不出来，但在某个时间窗口之后保证最终能读出来。

弱一致性和最终一致性一般来说是异步冗余的，而强一致性一般来说是同步冗余的，异步的通常意味着更好的性能，但也意味着更复杂的状态控制。同步意味着简单，但也意味着性能下降。

3 分布式事务

数据库事务：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是ACID。

CAP定理：

  • 一致性：所有节点在同一时间具有相同的数据。
  • 可用性：保证每个请求不管成功或者失败都有响应。我理解的是系统的性能。
  • 分区容忍性：系统中任意信息的丢失或失败不会影响系统的继续运作。我理解的是系统的抗故障能力。

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

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

4 实现分布式事务的方式

4.1 两阶段提交（2PC）

数据库支持的2PC，又叫做 XA Transactions。XA是一个两阶段提交协议，该协议分为以下两个阶段：

  • 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.
  • 第二阶段：事务协调器要求每个数据库提交数据。

2PC就是使用了XA协议的原理，通过引入协调者（Coordinator）来调度参与者的行为，并最终决定这些参与者是否要真正执行事务。

  1. 准备阶段：协调者询问参与者事务是否执行成功，参与者发回事务执行结果。 2pc_1
  2. 提交阶段：如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让所有参与者回滚事务。 2pc_2

注意：在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。

优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。

缺点：

  1. 同步阻塞问题： 执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
  2. 单点故障问题： 协调者在2PC中起到非常大的作用，发生故障将会造成很大影响。
  3. 数据不一致： 在阶段二，如果协调者只发送了部分Commit消息，此时网络发生异常，那么只有部分参与者接收到Commit消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
  4. 任意一个节点失败就会导致整个事务失败，没有完善的容错机制。

4.2 三阶段提交(3PC)

二阶段提交（2PC）的改进版本。三阶段提交有两个改动点。

  1. 引入超时机制。同时在协调者和参与者中都引入超时机制。
  2. 3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

在第一阶段，只是询问所有参与者是否可可以执行事务操作，并不在本阶段执行事务操作。当协调者收到所有的参与者都返回YES时，在第二阶段才执行事务操作，然后在第三阶段在执行commit或者rollback。

3pc

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

4.3 补偿事务(TCC)

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：

  • Try 阶段主要是对业务系统做检测及资源预留
  • Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
  • Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

举个例子，假入 Bob 要向 Smith 转账，思路大概是：

  1. 首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。
  2. 在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
  3. 如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些
缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

4.4 Paxos算法

详细介绍参见Paxos

4.5 Raft算法

详细介绍参见Raft
Raft 主要是用来竞选主节点。

参考文献

分布式
聊聊分布式事务，再说说解决方案
分布式一致性与共识算法
理解TCC、2PC和3PC
关于分布式事务、两阶段提交协议、三阶提交协议
深入理解分布式系统的2PC和3PC
分布式系统的事务处理
分布式系统原理九：CAP理论和BASE理论
分布式存储系统 知识体系