分布式一致性

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理论
分布式存储系统 知识体系