分布式事务解决方案
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
0 条评论
下一页
