视频课程
小黑屋思过中，禁止观看！
评论并刷新后可见

您需要在视频最下面评论并刷新后，方可查看完整视频

视频课程
立即观看
付费视频

您支付费用，方可查看完整视频

￥{{user.role.value}}
课程视频
开始学习
会员专享

视频合集

最全分布式事务解决方案详解

  • 课程笔记
  • 问答交流

分布式事务在电商、支付、金融等业务中是一个非常重要的技术场景，所以本节课我们就来重点解决分布式事务目前的主流解决方案。

我了助大家掌握好分布式事务，这节课我会重点讲解以下7点：

1.分布式事务

2.CAP

3.BASE

4.一致性模型

5.XA两阶段

6.事务补偿TCC

7.消息队列最终一致性

 

分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
最全分布式事务解决方案详解-mikechen

简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

1.单体应用
最全分布式事务解决方案详解-mikechen
2.微服务应用

随着业务需求的变化，单体应用被拆分成微服务应用，原来的模块被拆分成按照业务为单位的独立应用，分别使用独立的数据源，业务操作需要调用多个服务来完成。
最全分布式事务解决方案详解-mikechen

按照业务为单位进行数据拆分：

  • 垂直拆分
  • 水平拆分

按照业务为单位提供服务：

  • 商品中心
  • 交易中心
  • 积分中心

业务场景：

用户支付商品，这里我们会创建三个服务，一个交易服务(下支付订单)，一个商品服务(扣库存)，一个支付服务(扣余额)。
最全分布式事务解决方案详解-mikechen

业务流程：

  1. 当用户下单时，会在订单服务中创建一个订单。
  2. 然后通过远程调用库存服务来扣减下单商品的库存。
  3. 再通过远程调用账户服务来扣减用户账户里面的余额。
  4. 最后在订单服务中修改订单状态为已完成。

这个时候需要横跨多个服务，涉及订单、用户、商品库存、积分等多个数据库，而这些操作又需要在同一个事务中完，这就涉及到到了分布式事务。

这就是一个典型的分布式事务需求场景，我们需要一个分布式事务的解决方案保障业务全局的数据一致性。

CAP理论(强一致性)

1.一致性(Consistency)
更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。

2.可用性(Availability)
即服务一直可用，而且是正常响应时间。

3.分区容错性(Partition tolerance)
分布式系统在遇到任何网络分区故障的时候，仍热能够保证对外提供满足一致性或可用性的服务。

Base理论

最全分布式事务解决方案详解-mikechen
1.Basically Available（基本可用）
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性

2.Soft state（软状态）
允许系统中的数据存在中间状态，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

3.Eventually consistent（最终一致性）
系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

一致性模型

分布式系统的数据强一致性、弱一致性、最终一致性可以通过Quorum NRW算法分析。

1. 强一致性
数据更新成功后，任何时刻所有副本中的数据都是一致的，一般采用同步方式实现。

2. 弱一致性
数据更新成功后，系统不承诺立即同步到所有副本集，也不承诺具体多久后可以全部更新完毕。

3.最终一致性
数据更新成功后，系统保证最终会同步完毕。

分布式事务解决方案

最全分布式事务解决方案详解-mikechen

XA协议的两阶段提交

分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。

当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有参与者节点的操作结果并最终指示这些节点是否要把操作结果进行真正的提交。

因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

最全分布式事务解决方案详解-mikechen
XA是一个分布式事务协议，XA中大致分为两部分：

  • 全局事务管理器 TM（Transaction Manager）：TM是分布式事务的核心管理者。事务管理器与每个RM进行通信，协调并完成分布式事务的处理。发起一个分布式事务的MySQL客户端就是一个TM。
  • 局部资源管理器RM（Resource Manager）：用于直接执行本地事务的提交和回滚,在分布式集群中，一台MySQL服务器就是一个RM。

XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲两台机器理论上无法达 到一致的状态，需要引入一个单点进行协调。
事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。

备注：XA协议由Tuxedo首先提出，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。
最全分布式事务解决方案详解-mikechen

第一阶段：是 准备（prepare）阶段

即所有的RM锁住需要的资源，在本地执行这个事务（执行sql，写redo/undo log等），但不提交，然后向Transaction Manager报告已准备就绪。

第二阶段：是提交阶段（commit）

当TM确认所有参与者都准备好后，向所有参与者发送commit命令。如果有一个RM返回不可执行，则向所有RM发送rollback指令。

XA模式的缺点：
最全分布式事务解决方案详解-mikechen

  • 单点问题：如果事务管理器出现故障，资源管理器将一直处于锁定状态。
  • XA过程中会长时间的占用资源（加锁）直到两阶段提交完成才释放资源，对性能影响很大，不适合高并发、高性能场景，基本不适合解决微服务事务问题。

TCC模式

最全分布式事务解决方案详解-mikechen
TCC 是一种补偿型事务，该模型要求应用的每个服务提供 try、confirm、cancel 三个接口，它的核心思想是通过对资源的预留(提供中间态，如账户状态、冻结金额等)，尽早释放对资源的加锁，如果事务可以提交，则完成对预留资源的确认，如果事务要回滚，则释放预留的资源。
TCC模型完全交由业务实现，每个子业务都需要实现Try-Confirm-Cancel三个接口，对业务侵入大，资源锁定交由业务方。

1、Try：尝试执行业务，完成所有业务检查(一致性)，预留必要的业务资源(准隔离性)。

2、Confirm：确认执行业务，不再做业务检查。只使用Try阶段预留的业务资源，Confirm操作满足幂等性。

3、Cancel：取消执行业务释放Try阶段预留业务资源。

第一阶段

事务开始时，业务应用会向事务管理器注册启动事务。
业务应用会调用所有服务的try接口，预留资源，完成一阶段。

第二阶段

事务管理器会根据try接口返回情况，决定调用confirm接口或者cancel接口(资源是否需要)，用来清除第一阶段的影响。
最全分布式事务解决方案详解-mikechen

业务场景：

  • Try:完成业务的准备，比如：支付中
  • Confirm：完成业务的提交，比如：支付完成
  • Cancel：完成事务的回滚，比如：未支付

TCC方案其实是两阶段提交的一种改进，可以说 TCC 就是应用层的 2PC

  • Try 操作对应2PC 的一阶段准备(Prepare)
  • Confirm 对应 2PC 的二阶段提交(Commit)
  • Cancel 对应 2PC 的二阶段回滚(Rollback)

开源TCC分布式事务框架：

ByteTCC、Himly、TCC-transaction、EasyTransaction

TCC模式的缺点：

  • 对应用的侵入性强：业务逻辑原本的一个接口，要改造为 3 个逻辑，Try-Confirm-Cancel，应用侵入性较强，改造成本高。
  • 实现难度较大：要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等。
  • 一般借助TCC开源框架：ByteTCC，TCC-transaction，Himly、EasyTransaction。

总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

消息队列最终一致性方案

最全分布式事务解决方案详解-mikechen
通过消息队列保证上、下游应用数据操作的一致性。

设计思路：

将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。

下游应用向消息系统订阅该消息，收到消息后执行相应操作。

消息方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性

框架：

RocketMQ

业务无侵入方案

seata(fescar)

评论交流
  1. 路正银

    1.谈谈seata(fescar)分布式事务解决方案的实现原理？
    基于或者说参考了XA的实现，有全局事务和分事务，全局事务调度分事务，相比较于XA的两阶段提交，seata分事务第一阶段提交是真实提交（有commint）,同时做好回滚日志，所有分事务都结束之后，由总事务来决定是提交（分事务去删除回滚日志）还是rollback（各个分事务开始回滚）。

    2.再谈谈seata相对于XA两阶段与TCC的优缺点？
    相对于XA两阶段提交有效的降低了锁的粒度
    想对于TCC对业务代码的侵入极小

    3.最后谈谈XA两阶段、TCC、MQ事务、以及seata等分布式事务方案的应用场景？
    XA两阶段，保证数据的强一致性，底层是基于数据库实现的，锁的范围太大，不适合高并发场合
    TCC，数据一致性是在业务层实现的，需要同时在业务层实现正向逻辑和反向逻辑，开发维护难度大
    MQ事务，保证的数据的最终一致性，适用于对数据一致性要求实时性不太高的场合（不要求数据实时一致性）；上游事务和对发给下游事务的消息在一个事务里面，下游事务来消费消息（有重试机制）；对业务代码有侵入
    seata，对业务代码侵入极小，锁的粒度小

    • mikechen

      good?，谈到了锁的力度的问题就妥妥的了，继续，加油?。

      备注：从多线程开始的锁、再到数据库的锁、再到事务涉及的锁、分布式锁，你会发现锁无处不在，也是核心重点。正是因为XA两阶段的锁是两阶段都要锁，从TCC开始就开始优化，再到Seata这个版本，都是希望锁的粒度能降低的同时，去满足高性能的一致性要求这个整体方向。

❯
返回顶部