首页  思维导图  详情



 



分布式事务解决方案

2020-04-26 17:03:10   0  举报





AI智能生成

分布式事务

分布式事务、电商、支付、购物、回调、通知、订单

学习笔记

模板推荐

作者其他创作

大纲/内容

0. 理论基础

DTP模型

应用程序AP

Web应用，由ApplicationServer提供事务管理器

非Web应用，可以使用三方事务管理器类库，如Atomkios、JOTM

资源管理器RM

关系型数据库Mysql

消息中间件RabbitMQ

DB、MQ都是RM，由TM协调

JTA规范定义了一个XAResource接口（是RM提供给TM调用的接口），MQ、DB都需要实现，如MysqlXAConnection

事务管理器TM

提供事务声明、事务资源管理、事务上下文传播

通讯资源管理器CRM

TM之间通讯通过这个组件完成

通讯协议CP

JTA规范

JTA事务API

JTS事务服务

JTA规范在DTP模型之上，有多了Application Server

如：jboss、weblogic、websphere

并不是所有的容器都实现了JTA规范，如Tomcat并没有实现JTA规范，因此并不能提供事务管理器功能；

TCC事务模型 VS DTP事务模型

TCC两阶段和XA两阶段的区别和优缺点？

XA事务的优缺点

XA是资源层面，强一致性的，在两阶段提交过程中会一直持有锁

XA要求每个RM通过#串行化隔离级别#来保证全局一致性。串行化会导致本来不加锁的select快照读都加上锁

优点（最大作用）：普适性，可以横向扩展，提升非热点数据的并发性能

缺点：并不能提升热点数据性能，分布式事务的最高性能趋近于单机的本地事务

TCC事务的优缺点

TCC是应用层面，最终一致性，不会一直持有锁

多个独立的本地事务，属于补偿事务

优点：1、有效避免XA 2PC占用锁资源过长导致的性能问题 2、方便横向扩展业务资源

缺点：业务改造成本高，原本一个接口需要改造成try\confirm\cancel三个接口

2PC和3PC的区别？

理论落地实践

基于XA协议的2PC

理论层面：2PC、所有参与者必须实现prepare、commit、rollback接口

开源实现：Atomikos

http://www.tianshouzhi.com/api/tutorials/distributed_transaction/386

存在问题： 1、#2协调者挂了，事务悬挂； 2、#2参与者挂了，其他参与者是commit还是rollback？ 3、2PC的主要实现都在DB（依赖DB是否支持XA协议），而微服务通常是在服务层面实现一致性；

3PC没有彻底解决上面的问题

本地消息表

核心思想：将远程分布式事务拆分成一系列的本地事务

案例

#1. ServiceA 用户a扣款1W，通过本地事务插入消息到本地事务表

#2.通知ServiceB给用户b加上1W

那么问题来了，如何通知对方呢？

采用方式

Producer准备一张消息表，update DB和insert msg存在一个事务里面

定时任务轮询消息表，不断重传发送

Consumer准备一张判重表，实现业务幂等；

问题：消费成功、insert失败了怎么办？ ---可以使用手动确认消费；

适用场景

常见问题

需要解决的问题：先updateDB，后发mq？还是先发mq，后update DB？

结论：这2个操作都不是原子的，无论先操作谁都是有问题的

切记：MQ不能放事务里面，否则会导致长事务

基于MQ

支持事务MQ

基本流程

#第一阶段:prepared消息，会拿到消息地址

#第二阶段：执行本地事务

#第三阶段：通过第一阶段的消息地址拿到之前的消息，然后修改状态。消费者就可以拿到消息。

MQ消息层面的最终一致性

相比上面方案，其实就是把”扫描消息表“这个事变成消息中间件帮忙做了

优点：1.消息数据独立存储，与业务系统解耦；2. 业务系统接入成本低

缺点：1. 增加消息系统的维护成本

适用场景：1. 对时间敏感度比较低的场景，比如：会员注册服务和邮件发送服务之间

支持非事务MQ

TCC

通用性TCC

从服务是同步调用，会影响主服务决策

适用场景：执行时间确定且比较短的场景，如交易与支付、账务

异步确认型TCC

补偿型TCC

与通用型的区别是：通用型TCC需要提供Try\Confirm\Cancel三个接口；而补偿型只用DO和Compensate

DO:执行正向业务逻辑

Compensate:执行抵消逻辑

缺点：业务在一阶段就执行了完整的逻辑，在回滚时可能存在失败场景，需要人工介入

适用场景：并发较少或者需要与外部交互的场景，如机票预订

案例

蚂蚁金服分布式事务实践解析

https://zhuanlan.zhihu.com/p/112983373

常见问题

TCC如何解决2PC的问题？

Try成功之后，如果Confirm失败、或者Cancel失败，都是不同重试解决，这就要求接收方必须实现幂等；

TCC异常问题

空回滚

Try未执行，Cancel执行了

什么情况会造成空回滚？

Try超时（丢包）

幂等

怎么解决重复执行的幂等问题？

悬挂

什么情况会造成悬挂？

怎么实现防悬挂？

TCC异常控制？

Confirm不允许空回滚

Cancel允许空回滚

Seata

AT/FMT模式

基本思想

二阶段托管由框架执行，

没有隔离性

原理

Undo Log

保存执行前的快照

Redo Log

一阶段SQL执行之后，把新的快照存储到redo log

行锁表

记录表的主键和名称，用于并发控制

常见问题

会不会有脏读？如何解决？

分支主题

基于冲正模型实现Saga

核心思想：拆分长事务为多个短事务，Soga工作流引擎负责协调

使用前提

对服务的要求:1. 幂等；2.补偿可交换执行

Saga提供ACD保证

原子性：通过Saga协调器完成

一致性：本地事务+saga log

隔离性：saga不保证

持久性：saga log

常见问题

隔离性带来的脏读

业务层加锁

Session层隔离保证串行化操作

业务层用预扣资金隔离

业务层通过select for update当前读加锁保证隔离

案例

华为：Seata 长事务解决方案 Saga 模式

https://www.sofastack.tech/blog/sofa-channel-10-retrospect/

Saga分布式事务解决方案与实践

http://servicecomb.apache.org/cn/docs/distributed-transactions-saga-implementation/

基于服务的分布式事务(下篇)

http://servicecomb.apache.org/cn/docs/distributed-transaction-of-services-2/

文献

分布式事务解决方案与适用场景分析https://zhuanlan.zhihu.com/p/34232350

 Collect

Get Started

分布式事务解决方案-本地消息表

 Collect

Get Started

下单分布式事务解决方案

 Collect

Get Started

分布式解决方案

 Collect

Get Started

分布式事务解决方案





0 条评论

下一页