【分布式事务】分布式事务解决方案

转载：https://www.cnblogs.com/barrywxx/p/8533363.html

1 微服务的发展

微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样能够下降开发难度、加强扩展性、便于敏捷开发。当前被愈来愈多的开发者推崇，不少互联网行业巨头、开源社区等都开始了微服务的讨论和实践。Hailo有160个不一样服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴、腾讯、360、京东、58同城等不少互联网公司都进行了微服务化实践。当前微服务的开发框架也很是多，比较著名的有Dubbo、SpringCloud、thrift 、grpc等。

2 微服务落地存在的问题

虽然微服务如今如火如荼，但对其实践其实仍处于探索阶段。不少中小型互联网公司，鉴于经验、技术实力等问题，微服务落地比较困难。如著名架构师Chris Richardson所言，目前存在的主要困难有以下几方面：

1）单体应用拆分为分布式系统后，进程间的通信机制和故障处理措施变的更加复杂。

2）系统微服务化后，一个看似简单的功能，内部可能须要调用多个服务并操做多个数据库实现，服务调用的分布式事务问题变的很是突出。

3）微服务数量众多，其测试、部署、监控等都变的更加困难。

随着RPC框架的成熟，第一个问题已经逐渐获得解决。例如dubbo能够支持多种通信协议，springcloud能够很是好的支持restful调用。对于第三个问题，随着docker、devops技术的发展以及各公有云paas平台自动化运维工具的推出，微服务的测试、部署与运维会变得愈来愈容易。

而对于第二个问题，如今尚未通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。 为此，本文将深刻和你们探讨微服务架构下，分布式事务的各类解决方案，并重点为你们解读阿里巴巴提出的分布式事务解决方案----GTS。该方案中提到的GTS是全新一代解决微服务问题的分布式事务互联网中间件。

3 传统分布式事务解决方案

3.1 基于XA协议的两阶段提交方案

交易中间件与数据库经过 XA 接口规范，使用两阶段提交来完成一个全局事务， XA 规范的基础是两阶段提交协议。
第一阶段是表决阶段，全部参与者都将本事务可否成功的信息反馈发给协调者；第二阶段是执行阶段，协调者根据全部参与者的反馈，通知全部参与者，步调一致地在全部分支上提交或者回滚。

 

两阶段提交方案应用很是普遍，几乎全部商业OLTP数据库都支持XA协议。可是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

3.2 TCC方案

TCC方案在电商、金融领域落地较多。TCC方案实际上是两阶段提交的一种改进。其将整个业务逻辑的每一个分支显式的分红了Try、Confirm、Cancel三个操做。Try部分完成业务的准备工做，confirm部分完成业务的提交，cancel部分完成事务的回滚。基本原理以下图所示。

事务开始时，业务应用会向事务协调器注册启动事务。以后业务应用会调用全部服务的try接口，完成一阶段准备。以后事务协调器会根据try接口返回状况，决定调用confirm接口或者cancel接口。若是接口调用失败，会进行重试。

TCC方案让应用本身定义数据库操做的粒度，使得下降锁冲突、提升吞吐量成为可能。 固然TCC方案也有不足之处，集中表如今如下两个方面：

• 对应用的侵入性强。业务逻辑的每一个分支都须要实现try、confirm、cancel三个操做，应用侵入性较强，改形成本高。
• 实现难度较大。须要按照网络状态、系统故障等不一样的失败缘由实现不一样的回滚策略。为了知足一致性的要求，confirm和cancel接口必须实现幂等。

上述缘由致使TCC方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署，而TCC方案中不少事务的处理逻辑须要应用本身编码实现，复杂且开发量大。

3.3 基于消息的最终一致性方案

消息一致性方案是经过消息中间件保证上、下游应用数据操做的一致性。基本思路是将本地操做和发送消息放在一个事务中，保证本地操做和消息发送要么二者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操做。

 

消息方案从本质上讲是将分布式事务转换为两个本地事务，而后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用须要进行大量业务改造，成本较高。