码迷,mamicode.com
首页 > 编程语言 > 详细

[Java复习] 分布式事务 Part 1

时间:2019-12-14 21:20:27      阅读:81      评论:0      收藏:0      [点我收藏+]

标签:降级   2pc   取数   分布式   默认   核心   成功   confirm   理论   

1. CAP理论

C: Consistency 一致性

A: Availability 可用性

P: Partition tolerance 分区容错性

CAP定理:一个分布式系统不可能同时满足CAP三个要求,最多只能同时满足其中两项。

          技术图片

 

 

 

1.1. CA:

     放弃分区容错性,所有数据放一个节点,退回单机模式。

1.2. CP:

放弃可用性,一旦网络故障,受影响服务需要等待恢复时间,系统处于不可用状态。

1.3. AP:

    放弃一致性,这里指放弃强一致性,确保最终一致性。大多数分布式系统的选择。

 

2. BASE理论

BASE: Base Available(基本可用),Soft state(软状态), Eventually consistent(最终一致性)。

BASE是对CAP一致性和可用性权衡的结果。

      1. 基本可用:指分布式系统出现不可预知故障时,允许损失部分可用性,响应时间合理延长,服务上适当降级。

      2. 软状态: 允许分布式系统中的数据处于中间状态,允许各节点数据同步时存在延时。

      3. 最终一致性:允许系统中所有数据副本,在经过一段时间同步后,最终能够达到一个一致的状态。不需要实时保证系统的数据一致性。

 

3. 两阶段提交(2PC)

数据库支持2PC,又叫XA transactions。

MySQL从5.5版,Oracle从7版,SQL Server 2005开始支持。

XA是一个两阶段提交协议,协议分两阶段:

  第一阶段:事务协调器要求每个涉及到事务的数据库预提交/投票(pre commit)此操作,并反映是否可以提交。

  第二阶段:事务协调器要求每个数据库提交数据。

  如果有任何一个数据库否决此次提交,那么所有数据库都会被要求回滚它们在此事务中的那部分信息。

 

预提交/投票阶段:

  事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息,每个参与者要么直接返回失败(如权限验证失败),

  要么在本地执行事务,写本地的 redo 和 undo 日志,但不提交。

             技术图片

提交阶段:

  如果协调者收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息;

  否则,发送提交(Commit)消息;参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过

  程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

     技术图片

 

 2PC缺点:

  1. 同步阻塞。 执行过程中,所有节点都是事务阻塞的。

  2. 单点故障

    2.1. 协调者正常,参与者宕机

      协调者无法收集到所有参与者反馈,会陷入阻塞。

    2.2. 协调者宕机,参与者正常

      无论哪个阶段,协调者挂了,则无法发送提交请求,参与者会陷入阻塞。

    2.3. 协调者与参与者都宕机

      1). 发生在第一阶段,由于参与者都没有真正commit,则可以重新选出协调者,再执行2PC。

      2). 发生在第二阶段,并且挂了的参与者在挂之前并没有收到协调者指令。这种情况,新的协调者重新执行2PC。

      3). 发生在第二阶段,有部分参与者已经commit,产生数据不一致(脑裂)。2PC无法解决!

      4). 协调者发出commit后挂了,唯一接收到这条消息的参与者同时也挂了。则即使选举出新的协调者,这条事务状态也不确定,没人知道事务是否被已经提交。

 

4. 三阶段提交(3PC

3PC是2PC的改进版

3PC改进点:

  1. 同时在协调者和参与者引入超时机制。

  2. 在2PC的第一阶段和第二阶段中插入一个准备阶段,保证了在最后提交阶段之前各参与者状态时一致的。

 

3PC有CanCommit, PreCommit, DoCommit三个阶段。

  1. CanCommit阶段:

     2PC的第一阶段是本地事务执行结束后,最后不Commit。3PC的CanCommit是指尝试获取数据库锁,如果可以就返回Yes,进入预备状态,否则返回No。

  2. PreCommit阶段:

        如果上一阶段所有参与者都返回Yes,则进入PreCommit阶段进行事务预提交。这里协调者和参与者都引入超时机制。

        假如有任何一个参与者向协调者发送No,或者等待超时之后,协调者还没有收到参与者响应,则执行事务中断。

  3. DoCommit阶段:

       真正进行事务提交。

       包括 1. 协调者发送提交请求;2.参与者提交事务;3.参会者响应反馈(向协调者发送ACK);4.协调者确定事务完成。

 

5. TCC事务

  TCC: Try / Confirm / Cancel,可归纳为补偿型事务

  核心思想:针对每个操作,都有有一个与其对应的确认和补偿(撤销)操作。

    Try: 针对业务操作做检测(一致性)和资源预留(隔离性)。

    Confirm:对业务进行确认提交。默认Try成功并开始执行Confirm,Confirm一定成功。

    Cancel: 在业务执行错误,需要回滚时执行业务补偿,释放预留资源。

 

  TCC优点:

    1. 解决协调者单点故障的问题。

    2. 引入超时后进行补偿,并不会锁定整个资源,事务颗粒的变小。

    3. 通过补偿机制,由业务操作管理数据一致性。

  TCC缺点: 开发复杂,每个目标字段都需要一个预留(冻结)字段,需要写很多补偿代码,在一些业务场景不太好定义和处理。

  TCC使用场景:钱,金融等对事务要求非常高的核心业务场景。

 

总结: TCC使用于大部分接口是同步调用的场景,要么一起成功,要么一起回滚。但在实际系统中,可能服务之间的调用时异步的,通过消息中间件。

[Java复习] 分布式事务 Part 1

标签:降级   2pc   取数   分布式   默认   核心   成功   confirm   理论   

原文地址:https://www.cnblogs.com/fyql/p/12040616.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!