背景
本地事务
一个单体应用中事务由一个数据库管理,并且限制在单个进程中的事务.
不涉及多个数据来源.
优点:支持严格的ACID,可靠,高效,简单.
不足:没有分布式处理能力
隔离的最小单位有资源管理器(数据库)决定,如果数据库中的一条记录或整张表(innodb能锁一条记录)
本地事务过程:
开始会话
开始事务
操作1,操作2…操作N
提交事务/回滚事务
完成会话
全局事务(即标准分布式事务方案)
由全局事务管理器管理
相关概念:
事务管理器:管理全局事务状态与参与的资源,协同资源的一致/回滚
TX协议:
应用或应用服务器与事务管理器的接口
XA协议:
全局事务管理器与资源管理器的接口
全局事务过程:
开始全局事务
注册资源1
操作1,操作2…操作N
注册资源2
操作1,操作2…操作N
提交事务
针对资源管理器1上进行准备
针对资源管理器2上进行准备
在 资源管理器1上提交
在 资源管理器2上提交
以上是通过两阶段提交来实现的,那么什么是两阶段提交呢?
两阶段提交:
是XA在全局事务中协调多个资源的机制,采用两阶段方案来解决 一致性问题.由TM(相当于一个协调人)来参与事务最终提交.
事务管理器对数据库1上进行准备,对数据库2上进行准备,然后
提交数据库1上的数据,提交数据库2上的数据.
如果是回滚,也是同样的操作.
在JAVA EE平台中的标准分布式事务方案的如何实现?
通过jta(java 事务 API),和jts(java事务服务)来实现标准的分布式事务.
以上说的标准的分布式事务方案的实现由优点是:
符合严格的ACID,但是呢,
缺点是:
1 效率非常低,因为在全局事务方式下,全局事务管理器TM通过XA接口使用两阶段提交协议(2pc)与资源层(数据库)交互时,数据被锁定的时间跨越了整个事务,直到全局事务结束,比如,一个事务跨了3个数据库(这3个数据库在3个不同的服务器上,跨了服务器和网络,会有各种网络延迟),那么3个数据库中的相关数据都会同时被锁,直到事务全部完成后才解锁,这种情况下其他的操作这些数据的动作都要一直等待.所以效率低
2 同时两阶段提交(2pc)在事务处理过程中,参与者需要一直持有资源,直到整个分布式事务结束,这样当业务规模越来越大时,2pc局限性越明显,系统可伸缩性会很差.
3 XA协议系统开销大,只有支持XA协议的资源才能参与分布式事务(目前主流数据库都支持XA协议)
综上,得出结论:微服务架构下使用标准分布式解决方案不适用.
那么在微服务架构下如何处理分布式事务呢?
如下:
方案1
可靠消息最终一致性
应用场景:
对应支付系统会计异步记账业务
银行通知结果信息存储与驱动订单处理
方案特点:
确保业务数据可靠的前提下,实现业务数据的最终一致,在理想状态下基本是准实时一致.
行业应用案例:
支付宝,eBay,去哪儿
方案2
TCC事务补偿型
应用场景:
对应支付系统订单账户操作:订单处理,资金账户处理,积分账户处理
行业应用案例:
蚂蚁金融云的分布式事务服务DTS
方案3
最大努力通知型
应用场景:
对应支付系统的商户通知业务场景
行业应用案例:
银行通知,商户通知(多次通知,查询校对,对账文件)
总结:
刚性事务
全局事务(标准的分布式事务)
柔性事务:
可靠消息最终一致性(异步确认型)
TCC(两阶段型,补偿型)
最大努力通知型(非可靠消息,定期校对)
消息中间件的应用场景
消息中间件在分布式系统中的作用:
1 异步通信
2 解耦
3 并发缓冲