一图看懂整个分布式事务
2021-11-08 20:12:50 6 举报AI智能生成
分布式事务详解
作者其他创作
大纲/内容
3PC
概念
三阶段提交是为解决两阶段提交协议的缺点而设计的。
与两阶段区别
引入超时机制 - 同时在协调者和参与者中都引入超时机制。
在第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态是一致的
第一阶段：CanCommit
协调者事务询问，并开始等待
正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态；否则反馈No；
第二阶段：PreCommit
成功
协调者向所有参与者节点发出 preCommit 的请求，并进入 prepared 状态
参与者会执行事务操作，对应 2PC 准备阶段中的 “执行事务”，也会 Undo 和 Redo 信息记录到事务日志中
如果参与者成功执行了事务，就反馈 ACK 响应，同时等待指令：提交（commit） 或终止（abort）
失败
协调者向所有参与者节点发出 abort 请求 。
参与者如果收到 abort 请求或者超时了，都会中断事务。
第三阶段：Do Commit
成功
协调者接收到各参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送 doCommit 请求
参与者接收到 doCommit 请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
事务提交完之后，向协调者发送 ACK 响应。
协调者接收到所有参与者的 ACK 响应之后，完成事务。
失败
协调者向所有参与者发送 abort 请求。
参与者接收到 abort 请求之后，利用其在阶段二记录的 undo 信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
参与者完成事务回滚之后，向协调者发送 ACK 消息。
协调者接收到参与者反馈的 ACK 消息之后，完成事务的中断。
优缺点
优点
主要解决的单点故障问题，并减少了阻塞的时间
缺点
如有参与者节点出现了崩溃等情况而导致协调者始终无法获取所有参与者的响应信息，这时协调者将只能依赖协调者自身的超时机制来生效
TCC
概念
TCC事务机制相对于传统事务机制（X/Open XA），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。
初步操作 Try
尝试执行业务；
完成所有业务检查（一致性）；
预留必须业务资源（准隔离性）；
确认操作 Confirm
确认执行业务；
真正执行业务，不作任何业务检查；
只使用Try阶段预留的业务资源；
Confirm操作满足幂等性；
取消操作 Cancel
取消执行业务；
释放Try阶段预留的业务资源；
Cancel操作满足幂等性。
优缺点
优点
TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交
规避了数据库层的2PC性能低下问题
缺点
TCC的Try、Confirm和Cancel操作功能需业务提供，对业务的侵入强， 开发成本高。
Saga
概念
Saga模型把一个分布式事务拆分为多个本地事务，每个本地事务都有相应的执行模块和补偿模块。当Saga事务中任意一个本地事务出错时，可以通过调用相关的补偿方法恢复之前的事务，达到事务最终的一致性. Saga 强调的是ACD, 缺乏隔离性.
协调方式
协同式
把Saga的决策和执行顺序顺序逻辑分布在每一个参与方中, 通过交换事件完成整个事务.
好处
简单/松耦合
缺点
不好理解/多了之后乱/会产生循环依赖关系/紧耦合风险等
编排式
通过一个Saga编码器发送不同的命令驱动不同的Saga参与方, 指示他们完成各自的本地事务.
好处
依赖关系简单化/耦合少,彼此无感知,由编排器处理
缺点
编排器本身会变得复杂, 可能改一点东西考虑很多影响
事务分级
可补偿性事务
客户通过补偿进行回滚的事务
关键性事务
核心事务, 未必带补偿或者可以重复执行, 但是一旦成功其他的可以失败. 例如其他的可以通过消息来重复处理, 或者索性就失败通过人工流程之后处理.
可重复性事务
关键性之后的事务, 例如发送短信或者消息, 失败了可以重复执行
隔离策略
语义锁
这个就是程序级别的隔离, 例如审核状态变成审核中, 提交变成提交中来隔离, 但是一开始就设计好工作量很大
重读值
事务开始前就保留一份数据, 处理过程中验证是否应修改.
缺乏隔离的问题
脏读问题, 一个事务未完成,另外一个已经读取了
脏写问题, 接上面: 第一个事务回滚了,第二个事务之后可能使用脏数据写库
延伸
一致性算法Paxos
出自一位 Google 大神之口。Paxos 也是出名的 晦涩难懂，推理过程极其复杂。
一致性协议Raft
这个过程如同选举一样，参选者 需要说服 大多数选民 (服务器) 投票给他，一旦选定后就跟随其操作。
Leader（领袖）
Follower（群众）
Candidate（候选人）
Follower（群众）
Candidate（候选人）
对比
概念
CAP
C（一致性）
P（分区容错性）
A（可用性）
BASE
基本可用（Basically Available）
1. 响应时间上的损失
正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果
2. 功能上的损失
在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
软状态（Soft State）
相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”，我们可以把符合传统的ACID叫做刚性事务。
软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
最终一致性（Eventually Consistent）
定义：数据的最终一致有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。
分类
因果一致性（Causal consistency）
如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。
读己之所写（Read your writes）
节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。
会话一致性（Session consistency）
系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
单调读一致性（Monotonic read consistency）
如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
单调写一致性（Monotonic write consistency）
一个系统要能够保证来自同一个节点的写操作被顺序的执行。
最大努力交付（best-effort delivery）
XA
概念
XA是X/Open CAE Specification (Distributed Transaction Processing)模型
组件
应用程序（ AP ）
事务管理器（ TM ）：交易中间件等
资源管理器（ RM ）：关系型数据库等
通信资源管理器（ CRM ）：消息中间件等
现状
性能问题比较严重（阻塞性协议，增加响应时间、锁时间、死锁）
数据库支持完善度（MySQL 5.7之前都有缺陷）；
协调者依赖独立的J2EE中间件（早期重量级Weblogic、Jboss、后期轻量级Atomikos、Narayana和Bitronix）；
并不是所有资源都支持XA协议；
大厂懂所以不使用，小公司不懂所以不敢用。
1PC
概念
主程序负责一次性调用多方的提交操作， 如果发生错误则调用多方的回滚操作
2PC
概念
每个参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报，决定各参与者是否要提交操作还是中止操作。
第一阶段：准备阶段（投票阶段）
协调者事务询问，并开始等待
参与者执行事务
参与者反馈事务询问的响应
第二阶段：提交阶段（执行阶段）
成功
协调者向所有参与者发出commit请求
参与者节点正式完成操作，并释放在整个事务期间内占用的资源
参与者节点向协调者节点发送"完成"消息
协调者节点收到所有参与者节点反馈的"完成"消息后，完成事务
失败
协调者节点向所有参与者节点发出"回滚操作"的请求
参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源
参与者节点向协调者节点发送"回滚完成"消息
协调者节点收到所有参与者节点反馈的"回滚完成"消息后，取消事务
优缺点
优点
原理简单，实现方便
缺点
二阶段提交算法的最大缺点就在于它的执行过程中间，节点都处于阻塞状态
如有参与者节点出现了崩溃等情况而导致协调者始终无法获取所有参与者的响应信息，这时协调者将只能依赖协调者自身的超时机制来生效
LPO
概念
这是另外一个重要的优化： “最末参与者优化”（Last Participant Optimization，术语来自支付宝），即允许两阶段提交协议中有一个参与者不实现“准备”操作，在其余参与者都prepare ok的情况下，直接提交自己的分式事务。
Seata架构
概念
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。TXC（Taobao Transaction Constructor，阿里于2014开始着手解决分布式事务的内部框架）-》GTX（Global Transaction Service，阿里于2016年将TXC发布于云服务并且改名为GTX）-》Fescar（阿里于2019将GTS开源并改名为Fescar）-》Seata（Simple Extensible Autonomous Transaction Architecture，阿里将蚂蚁金服框架DTX与Fescar结合并且改名为Seata）
优缺点
优点
应用层基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性；
将分布式事务中TC（事务协调者）独立部署，负责事务的注册、回滚；
通过全局锁实现了写隔离与读隔离， 没有了脏读、幻读的问题
缺点
死锁问题
Seata的引入全局锁会额外增加死锁的风险，但如果实现死锁，会不断进行重试，最后靠等待全局锁超时，这种方式并不优雅，也延长了对数据库锁的占有时间。
热点数据
全局锁的引入实现了隔离性，但带来的问题就是阻塞，降低并发性，尤其是热点数据，这个问题会更加严重。
性能损耗
为了进行自动补偿，需要对所有交易生成前后镜像并持久化， 并同步undo log生成记录
GTS
概念
GTS（Global Transaction Service 全局事务服务）是阿里云上的分布事务中间件产品，用于实现分布式环境下特别是微服务架构下的高性能事务一致性。
简单来讲，Seata 项目 2019 年之初的创建是 GTS 的开源版本，经过一年的演进，GTS 商业版本开始全面提供对 Seata 的支持。
历史
- 2014 年，阿里巴巴中间件团队发布分布式事务中间件产品 TXC（Taobao Transaction Constructor），为集团内部应用提供服务。
- 2016 年，TXC 经过产品化改造，以 GTS 的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品，在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。
- 2019 年，阿里巴巴中间件团队基于 TXC 和 GTS 的技术积累，发起了开源项目 Seata（曾用名 Fescar），和社区一起建设这个分布式事务解决方案。开源项目 Seata 的基础是基于 GTS 架构定义的分布式事务框架以及 GTS 独创的的 AT（Automatic Transaction）模式。
- Seata 项目经过近一年的发展，收获包括蚂蚁金服分布式事务领域核心技术合作，以及开源社区的大力投入，加入 TCC 和 Saga 模式支持，于 2019 年底发布 GA 版本。
- 2020 年 2 月，基于 Seata 项目 GA 后的版本，GTS 实现与 Seata 的协议兼容，支持使用 Seata 的应用无缝迁移到云上基于 GTS 提供的服务来高效运行。
0 条评论
下一页
