分布式事务：不过是在一致性、吞吐量和复杂度之间，作一个选择

微服务架构流行的今天，一次交易须要跨越多个“服务”、多个数据库来实现，传统的技术手段，已经没法应对和知足微服务状况下这些复杂的场景了。针对微服务下的交易业务如何保障数据一致性，本文尽可能作到理论结合实际，将咱们在实际产品中用到的分布式事务实现机制，和你们扒一扒，但愿能帮助到读者。


谈到分布式事务，必须先把”CAP"拿出来讲说事......，固然还有”BASE"......


从架构的角度来看，业务拆分（数据分区）、数据一致性、性能（可用性）永远是个平衡的艺术：


1）在微服务架构下，为了得到更高的性能与灵活性，将业务应用拆分为多个，交易跨多个微服务编排，数据一致性的问题产生；

2）为了解决数据一致性问题，须要采用不一样的事务机制来保障，这又会产生性能（可用性）问题；


在计算机世界里，为了解决一件事情，另外的问题就会接踵而至，从另外一个层面印证了IT架构永远是一种平衡的艺术。


“BASE”其核心思想是根据业务特色，采用适当的方式来使系统达到最终一致性(Eventualconsistency)；在互联网领域，一般须要牺牲强一致性来换取系统的高可用性，只须要保证数据的“最终一致”，只是这个最终时间须要在用户能够接受的范围内；但在金融相关的交易领域，仍然须要采用强一致性的方式来保障交易的准确性与可靠性。

 

分布式事务介绍


接下来为你们介绍业界常见的事务处理模式，包括两阶段提交、三阶段提交、Sagas长事务、补偿模式、可靠事件模式（本地事件表、外部事件表）、可靠事件模式（非事务消息、事务消息）、TCC等。不一样的事务模型支持不一样的数据一致性。若是读者对这几种分布式事务比较熟悉，能够直接参考下图并结合自身业务需求选择合适的事务模型。



1、两阶段提交、三阶段提交


这种分布式事务解决方案目前在各类技术平台上已经比较成熟：JavaEE架构下面的JTA事务（各应用服务器均提供了实现，tomcat除外）。


目前两阶段提交、三阶段提交存在以下的局限性，并不适合在微服务架构体系下使用：


1）全部的操做必须是事务性资源（好比数据库、消息队列、EJB组件等），存在使用局限性（微服务架构下多数使用HTTP协议），比较适合传统的单体应用；

2）因为是强一致性，资源须要在事务内部等待，性能影响较大，吞吐率不高，不适合高并发与高性能的业务场景；


2、Sagas长事务


在Sagas事务模型中，一个长事务是由一个预先定义好执行顺序的子事务集合和他们对应的补偿子事务集合组成的。典型的一个完整的交易由T一、T二、......、Tn等多个业务活动组成，每一个业务活动能够是本地操做、或者是远程操做，全部的业务活动在Sagas事务下要么所有成功，要么所有回滚，不存在中间状态。



Sagas事务模型的实现机制：


1）每一个业务活动都是一个原子操做；

2）每一个业务活动均提供正反操做；

3）任何一个业务活动发生错误，按照执行的反顺序，实时执行反操做，进行事务回滚；

4）回滚失败状况下，须要记录待冲正事务日志，经过重试策略进行重试；

5）冲正重试依然失败的场景，提供定时冲正服务器，对回滚失败的业务进行定时冲正；

6）定时冲正依然失败的业务，等待人工干预；


Sagas长事务模型支持对数据一致性要求比较高的场景比较适用，因为采用了补偿的机制，每一个原子操做都是先执行任务，避免了长时间的资源锁定，能作到实时释放资源，性能相对有保障。


Sagas长事务方式若是由业务去实现，复杂度与难度并存。在咱们实际使用过程当中，开发了一套支持Sagas事务模型的框架来支撑业务快速交付。



开发人员：业务只须要进行交易编排，每一个原子操做提供正反交易；


配置人员：能够针对异常类型设定事务回滚策略（哪些异常归入事务管理、哪些异常不归入事务管理）；每一个原子操做的流水是否持久化（为了避免同性能能够支持缓存、DB、以及扩展其它持久化方式）；以及冲正选项配置（重试次数、超时时间、是否实时冲正、定时冲正等）；


Sagas事务框架：提供事务保障机制，负责原子操做的流水落地，原子操做的执行顺序，提供实时冲正、定时冲正、事务拦截器等基础能力；


Sagas框架的核心是IBusinessActivity、IAtomicAction。IBusinessActivity完成原子活动的enlist()、delist()、prepare()、commit()、rollback()等操做；IAtomicAction主要完成对状态上下文、正反操做执行。



限于文章篇幅，本文不对具体实现作详述；后面找时间能够详细介绍基于Sagas长事务模型具体的实现框架。


Sagas长事务须要交易提供反操做，支持事务的强一致性，因为没有在整个事务周期内锁定资源，对性能影响较小，适合对数据要求比较高的场景中使用。


3、补偿模式


Sagas长事务模型本质上是补偿机制的复杂实现，若是实际业务场景上不须要复杂的Sagas事务框架支撑，能够在业务中实现简单的补偿模式。补偿过程每每也一样须要实现最终一致性，须要保证取消服务至少被调用一次和取消服务必须实现幂等性。补偿模式能够参见同事田向阳的技术文章《微服务架构下数据一致性保证（三）》（相关文章：微服务架构下数据一致性保障(一)   微服务架构下数字一致性保证(二)）



补偿机制不推荐在复杂场景（须要多个交易的编排）下使用，优势是很是容易提供回滚，并且依赖的服务也很是少，与Sagas长事务比较来看，使用起来更简便；缺点是会形成代码量庞大，耦合性高，对应没法提供反操做的交易不适合。


4、可靠时间模式

（本地事件表、外地事件表）


可靠事件模式属于事件驱动架构，当某件重要事情发生时，例如更新一个业务实体，微服务会向消息代理发布一个事件。消息代理会向订阅事件的微服务推送事件，当订阅这些事件的微服务接收此事件时，就能够完成本身的业务，也可能会引起更多的事件发布。



可靠事件模式在于保证可靠事件投递和避免重复消费，靠事件投递定义为:


1）每一个服务原子性的业务操做和发布事件;

2）消息代理确保事件传递至少一次；避免重复消费要求服务实现幂等性。


基于事件模式，须要重点考虑的是事件的可靠到达，在咱们产品实际支持过程当中，一般有本地事件表、外部事件表两种模式：


一、本地事件表方法将事件和业务数据保存在同一个数据库中，使用一个额外的“事件恢复”服务来恢复事件，由本地事务保证更新业务和发布事件的原子性。考虑到事件恢复可能会有必定的延时，服务在完成本地事务后可当即向消息代理发布一个事件。




1）微服务在同一个本地事务中记录业务数据和事件；


2）微服务实时发布一个事件当即通知关联的业务服务，若是事件发布成功当即删除记录的事件；


3）事件恢复服务定时从事件表中恢复未发布成功的事件，从新发布，从新发布成功才删除记录的事件；


其中第2条的操做主要是为了增长发布事件的实时性，由第三条保证事件必定被发布。


本地事件表方式业务系统和事件系统耦合比较紧密，额外的事件数据库操做也会给数据库带来额外的压力，可能成为瓶颈。


二、外部事件表方法将事件持久化到外部的事件系统，事件系统需提供实时事件服务以接受微服务发布事件，同时事件系统还须要提供事件恢复服务来确认和恢复事件。




1）业务服务在事务提交前，经过实时事件服务向事件系统请求发送事件，事件系统只记录事件并不真正发送；     


2）业务服务在提交后，经过实时事件服务向事件系统确认发送，事件获得确认后，事件系统才真正发布事件到消息代理；


3）业务服务在业务回滚时，经过实时事件向事件系统取消事件；


4）若是业务服务在发送确认或取消以前中止服务了怎么办呢？事件系统的事件恢复服务会按期找到未确认发送的事件向业务服务查询状态，根据业务服务返回的状态决定事件是要发布仍是取消；


该方式将业务系统和事件系统独立解耦，均可以独立伸缩。可是这种方式须要一次额外的发送操做，而且须要发布者提供额外的查询接口。

 

基于可靠事件的事务保障模式能够有不少的变种实现，好比对消息可靠性不高的话，有以下作法：

1）将本地表的方式换作缓存方式；

为了提升消息投递的效率，能够：

2）屡次消息合并投递模式；

为了提供强一致性的事务保障，甚至能够采用：

3）本地消息表持久化（保障发方法消息可靠落地）+远程消息表持久化（保障接收方消息可靠落地）结合的模式。

   

在咱们的流程产品中针对业务和流程的分布式事务解决方案就采用了屡次消息合并投递+本地缓存+远程消息表持久化的模式，接下来为你们介绍具体的使用方式。


使用场景

在实际业务项目中一般采用业务与流程分布式部署的模式，业务系统经过远程接口访问流程引擎，业务数据同流程数据存放到各自的数据库中。



在这种场景中，若是业务系统的流程操做和业务操做交叉在一块儿，当流程操做成功，而业务操做失败时，就会形成业务回滚，而流程在引擎端已经建立，致使业务系统和流程引擎状态不一致。       



在业务应用中对一个事务中的流程操做采用本地缓存+批量投递+远程落地的模式（若是须要在客户端确保消息可靠性，能够将本地缓存换成本地表的方式）；在流程引擎端在消息投递来以后，作了消息表落地的工做，保障可靠执行。在咱们流程产品中流程引擎对外提供的客户端提供了统一的分布式事务API，和使用传统本地事务同样进行操做，保证了透明性，简化开发人员的复杂度。分布式事务API支持两种协议模式：     

一、http+二进制序列化的模式

二、WebService模式


后续咱们会增长Restful风格的接口。

     

可靠事件模式在互联网公司中有着较大规模的应用，该方式适合的业务场景很是普遍，并且可以作到数据的最终一致性，缺点是该模式实现难度较大，依赖数据库实现可靠性，在高并发场景下可能存在性能瓶颈，须要在公司层面搭建一套标准的可靠事件框架来支撑。



5、可靠事件模式

（非事务消息、事务消息）


可靠事件模式的事件通知能够采用消息的模式来实现，其实现原理和本地事件表、外部事件表一致，本文就不在详述。目前经常使用的消息框架ActiveMQ、RabbitMQ、Kafka、RocketMQ能够用来做为消息投递的渠道。注意：Kafka一般不适合，由于Kafka的设计存在丢消息的场景。


目前市面上支持事务的消息产品比较少，RocketMQ虽然实现了可靠的事务模式，但并无开源出来、没有开源出来、没有开源出来，顺便说一下国内的开源有太多须要改进的空间（关键点不开源，开源后没有持续的投入）。

 

6、TCC模式


一个完整的TCC业务由一个主业务服务和若干个从业务服务组成，主业务服务发起并完成整个业务活动，TCC模式要求从服务提供三个接口：Try、Confirm、Cancel。·



1) Try：完成全部业务检查

预留必须业务资源     


2) Confirm：真正执行业务

不做任何业务检查；只使用Try阶段预留的业务资源；Confirm操做知足幂等性；


3) Cancel：

释放Try阶段预留的业务资源；Cancel操做知足幂等性；


整个TCC业务分红两个阶段完成：




第一阶段：主业务服务分别调用全部从业务的try操做，并在活动管理器中登记全部从业务服务。当全部从业务服务的try操做都调用成功或者某个从业务服务的try操做失败，进入第二阶段。


第二阶段：活动管理器根据第一阶段的执行结果来执行confirm或cancel操做。若是第一阶段全部try操做都成功，则活动管理器调用全部从业务活动的confirm操做。不然调用全部从业务服务的cancel操做。


TCC模式的详细描述能够参见同事田向阳的技术文章《微服务架构下数据一致性保证（三）》

     

须要注意的是第二阶段confirm或cancel操做自己也是知足最终一致性的过程，在调用confirm或cancel的时候也可能由于某种缘由（好比网络）致使调用失败，因此须要活动管理支持重试的能力，同时这也就要求confirm和cancel操做具备幂等性。

     

总结


六种分布式事务的实现模式从数据一致性、事务级别、吞吐量、实现的复杂度各有优劣，下图为你们提供选择依据。



站在架构设计的角度，针对数据一致性须要把业务因素考虑进来，这有利于团队在技术上做出更合理的选择。根据具体业务场景，评估出业务对事务的优先级，更有利于做出架构上的取舍。咱们常常接触的证券、金融、支付等行业，对数据一致性要求极高，须要严格的实时保证要求；但对于基于社交类的应用场景，能够采用局部实时一致，最终全局一致的能力。所以你们在实践过程当中，必定要把技术与业务结合，选择适合自身业务的技术方案。