分布式服务的事务如何处理

首先是不建议采用XA两阶段提交方式去处理分布式事务，要知道要可以支持XA分布式事务，必须是要实现XA规范才能够，而Service自己是无状态的，若是这样去作了等因而把Service内部的东西暴露了出去。对于分布式事务最好的方式仍是事务补偿或者BASE基于消息的最终一致性。

能够设想一个最简单的分布式事务场景，对于跨银行的转帐操做，该操做涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务自己无状态且独立，构成一个完整的事务。对于事务的处理初步分析:

事务补偿机制

事务补偿即在事务链中的任何一个正向事务操做，都必须存在一个彻底符合回滚规则的可逆事务。若是是一个完整的事务链，则必须事务链中的每个业务服务或操做都有对应的可逆服务。对于Service服务自己无状态，也不容易实现前面讨论过的经过DTC或XA机制实现的跨应用和资源的事务管理，创建跨资源的事务上下文。所以也较难以实现真正的预提交和正式提交的分离。

在这种状况下以上面例子来讲，首先调用取款服务，彻底调用成功并返回，数据已经持久化。而后调用异地的存款服务，若是也调用成功，则自己无任何问题。若是调用失败，则须要调用本地注册的逆向服务（本地存款服务），若是本地存款服务调用失败，则必须考虑重试，若是约定重试次数仍然不成功，则必须log到完整的不一致信息。也能够是将本地存款服务做为消息发送到消息中间件，由消息中间件接管后续操做。

在上面方式中能够看到须要手工编写大量的代码来处理以保证事务的完整性，咱们能够考虑实现一个通用的事务管理器，实现事务链和事务上下文的管理。对于事务链上的任何一个服务正向和逆向操做均在事务管理和协同器上注册，由事务管理器接管全部的事务补偿和回滚操做。

基于消息的最终一致性

在这里首先要回答的是咱们须要时实时一致性仍是最终一致性的问题，若是须要的是最终一致性，那么BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。

仍是以上面的例子来看。对于转帐操做，原有的两个服务调用变化为第一步调用本地的取款服务，第二步发送异地取款的异步消息到消息中间件。若是第二步在本地，则保证事务的完整性基本无任何问题，即自己就是本地事务的管理机制。只要两个操做都成功便可以返回客户成功。

因为解耦，咱们看到客户获得成功返回的时候，若是是上面一种状况则异地卡立刻就能查询帐户存款增长。而第二种状况则不必定，由于自己是一种异步处理机制。消息中间件获得消息后会去对消息解析，而后调用异地银行提供的存款服务进行存款，若是服务调用失败则进行重试。

异地银行存款操做不该该长久地出现异常而没法使用，所以一旦发现异常咱们能够迅速的解决，消息中间件中异常服务天然会进行重试以保证事务的最终一致性。这种方式假设问题必定能够解决，在不到万不得已的状况下本地的取款服务通常不进行可逆操做。

在本地取款到异地存款两个服务调用之间，会存在一个真空期，这段时间相关现金不在任何一个帐户，而只是在一个事务的中间状态，可是客户并不关心这个，只要在约定的时间保证事务最终的一致性便可。

关于等幂操做的问题

重复调用屡次产生的业务结果与调用一次产生的业务结果相同，简单点讲全部提供的业务服务，不论是正向仍是逆向的业务服务，都必需要支持重试。由于服务调用失败这种异常必须考虑到，不能由于服务的屡次调用而致使业务数据的累计增长或减小。

关因而否能够补偿的问题

在这里咱们谈的是多个跨系统的业务服务组合成一个分布式事务，所以在对事务进行补偿的时候必需要考虑客户须要的是否必定是最终一致性。客户对中间阶段出现的不一致的承受度是如何的。

在上面的例子来看，若是采用事务补偿机制，基本能够是作到准实时的补偿，不会有太大的影响。而若是采用基于消息的最终一致性方式，则可能整个周期比较长，须要较长的时间才能给获得最终的一致性。好比周六转款，客户可能下周一才获得通知转帐不成功而进行了回退，那么就必需要考虑客户是否能给忍受。

其次对于前面讨论，若是真正须要的是实时的一致性，那么即便采用事务补偿机制，也没法达到实时的一致性。即极可能在两个业务服务调用中间，客户前台业务操做对持久化的数据进行了其它额外的操做。在这种模式下，咱们不得不考虑须要在数据库表增长业务状态锁的问题，即整个事务没有完整提交并成功前，第一个业务服务调用虽然持久化在数据库，可是仍然是一个中间状态，须要经过业务锁来标记，控制相关的业务操做和行为。可是在这种模式下无疑增长了整个分布式业务系统的复杂度。