分布式(一致性 可用性 可用性)-CAP理论概述-分布式事务(2PC-3PC-TCC)

Posted 小吴吃肉啦~

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式(一致性 可用性 可用性)-CAP理论概述-分布式事务(2PC-3PC-TCC)相关的知识,希望对你有一定的参考价值。

一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项

  • 数据一致性(consistency):如果系统对一个写操作返回成功,那么之后的读请求都必须读到这个新数据;如果返回失败,那么所有读操作都不能读到这个数据,对调用者而言数据具有强一致性 又叫原子性 线性一致性
  • 服务可用性(availability):所有读写请求在一定时间内得到响应,可终止、不会一直等待
  • 分区容错性(partition-tolerance):在网络分区的情况下,被分隔的节点仍能正常对外服务

一致性

一致性可以分为强一致性与弱一致性,

​ 强一致性既复制是同步的 强一致性:系统中的某个数据被成功更新后,后续任何对改数据的读取的操作都将得到更新后的值

​ 若一致性,既复制是异步的 弱一致性:系统中的某个数据被成功更新后,后续任何对改数据的读取的操作可能得到更新后的值,也可能是更改前的值

最终一致性:是弱一致性的特殊形式,存储系统保证在没有更新的条件下,最终所有的访问都是最后更新的值

二阶段提交------2PC

2PC(Two-phase commit protocol),中文叫二阶段提交。 二阶段提交是一种强一致性设计,2PC 引入一个事务协调者的角色来协调管理各参与者(也可称之为各本地资源)的提交和回滚,二阶段分别指的是准备(投票)提交两个阶段。

参与角色

  • 协调者:事务的发起者
  • 参与者:事务的执行者

参与角色

  • 协调者:事务的发起者
  • 参与者:事务的执行者

第一阶段(voting phase投票阶段)():

  1. 协调者向所有参与者发送事务内容,询问是否可以提交事务,并等待答复
  2. 各参与者执行事务操作,将 undo 和 redo 信息记入事务日志中(但不提交事务)
  3. 如参与者执行成功,给协调者反馈同意,否则反馈中止

第二阶段(commit phase提交执行阶段):

当协调者节点从所有参与者节点获得的相应消息都为同意时:

  1. 协调者节点向所有参与者节点发出正式提交(commit)的请求。
  2. 参与者节点正式完成操作,并释放在整个事务期间内占用的资源。
  3. 参与者节点向协调者节点发送ack完成消息。
  4. 协调者节点收到所有参与者节点反馈的ack完成消息后,完成事务。

假如在第一阶段有一个参与者返回失败,那么协调者就会向所有参与者发送回滚事务的请求,即分布式事务执行失败。
2PC 是一个同步阻塞协议,像第一阶段协调者会等待所有参与者响应才会进行下一步操作,当然第一阶段的协调者有超时机制,假设因为网络原因没有收到某参与者的响应或某参与者挂了,那么超时后就会判断事务失败,向所有参与者发送回滚命令。

3PC

3PC 的出现是为了解决 2PC 的一些问题,相比于 2PC 它在参与者中也引入了超时机制,并且新增了一个阶段使得参与者可以利用这一个阶段统一各自的状态。

3PC 包含了三个阶段,分别是准备阶段、预提交阶段和提交阶段,对应的英文就是:CanCommit、PreCommit 和 DoCommit

在第一阶段和第二阶段中插入了一个准备阶段,保证了在最后提交阶段之前个参与节点的状态是一致的

看起来是把 2PC 的提交阶段变成了预提交阶段和提交阶段

(eg: 班长是协调者, 让全班每个人发信息问周末是否有时间聚餐,每个同学都给班长回复有时间,这是 班长在执行第二步, 通知全班同学在某个时间和某个地点吃饭, 同学们收到后 回复收到)

首先准备阶段的变更成不会直接执行事务,而是会先去询问此时的参与者是否有条件接这个事务,因此不会一来就干活直接锁资源,使得在某些资源不可用的情况下所有参与者都阻塞着。

而预提交阶段的引入起到了一个统一状态的作用,它像一道栅栏,表明在预提交阶段前所有参与者其实还未都回应,在预处理阶段表明所有参与者都已经回应了。

3PC 就是通过引入预提交阶段来使得参与者之间的状态得到统一,也就是留了一个阶段让大家同步一下。

事务补偿TCC

2PC 和 3PC 都是数据库层面的,而 TCC 是业务层面的分布式事务,就像我前面说的分布式事务不仅仅包括数据库的操作,还包括发送短信等,这时候 TCC 就派上用场了!

TCC 指的是Try - Confirm - Cancel。

Try 指的是预留,即资源的预留和锁定, 注意是预留。
Confirm 指的是确认操作,这一步其实就是真正的执行了。
Cancel 指的是撤销操作,可以理解为把预留阶段的动作撤销了。
其实从思想上看和 2PC 差不多,都是先试探性的执行,如果都可以那就真正的执行,如果不行就回滚。

比如说一个事务要执行A、B、C三个操作,那么先对三个操作执行预留动作。如果都预留成功了那么就执行确认操作,如果有一个预留失败那就都执行撤销动作。

以上是关于分布式(一致性 可用性 可用性)-CAP理论概述-分布式事务(2PC-3PC-TCC)的主要内容,如果未能解决你的问题,请参考以下文章

分布式理论二:BASE理论

分布式系统的CAP理论

简单说说分布式系统的CAP理论

浅谈分布式领域的CAP理论

分布式系统基础理论之CAP理论

D分布式系统的CAP理论