分布式事务伴随着微服务被人们一再提起。服务与服务之间的事务怎么处理比较好？到底使用哪种选择方案比较好。相信有人觉得分布式事务实现起来比较困难甚至不可能。也有人觉得2pc或3pc就够了等等。本文接下来尝试对2或3pc、补偿、事件源、聚合内事务进行逐一探讨，以求对这四种方式获得一个基本的认识。不妥之处欢迎指正。
两阶段、三阶段提交
两阶段提交要求及时的确认（comfirm）。然而这在很多场景下根本就不适用。因为很多场景是异步的。
而且很多的nosql数据库根本不支持acid事务，更别说2pc了。所以2pc还是3pc都是不可行的。至少在微服务中不是最佳选择。
所以不建议采用2pc或者3pc去处理分布式事务，要知道要能够支持2pc分布式事务，必须是要按照他的规范来才可以，而Service本身是无状态的，如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者基于消息的最终一致性。
在前面的文中我们也提到了分布式事务微服务业务开发三个难题－拆分、事务、查询（下） 我们可以设想一个最简单的分布式事务场景，对于跨银行的转账操作，该操作涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。
对于事务的处理初步分析: 补偿机制 事务补偿即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。 在这种情况下以上面例子来说，首先调用取款服务，完全调用成功并返回，数据已经持久化。然后调用异地的存款服务，如果也调用成功，则本身无任何问题。如果调用失败，则需要调用本地注册的逆向服务（本地存款服务），如果本地存款服务调用失败，则必须考虑重试，如果约定重试次数仍然不成功，则必须log到完整的不一致信息。也可以是将本地存款服务作为消息发送到消息中间件，由消息中间件接管后续操作。 在上面方式中可以看到需要手工编写大量的代码来处理以保证事务的完整性，我们可以考虑实现一个通用的事务管理器，实现事务链和事务上下文的管理。对于事务链上的任何一个服务正向和逆向操作均在事务管理和协同器上注册，由事务管理器接管所有的事务补偿和回滚操作。 事件源机制
在这里首先要说的是我们需要的是实时一致性还是最终一致性的问题，如果需要的是最终一致性，那么事件源策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。 还是以上面的例子来看。对于转账操作，原有的两个服务调用变化为第一步调用本地的取款服务，第二步发送异地取款的异步消息到消息中间件。如果第二步在本地，则保证事务的完整性基本无任何问题，即本身就是本地事务的管理机制。只要两个操作都成功即可以返回客户成功。 由于解耦，我们看到客户得到成功返回的时候，如果是上面一种情况则异地卡马上就能查询账户存款增加。而第二种情况则不一定，因为本身是一种异步处理机制。消息中间件得到消息后会去对消息解析，然后调用异地银行提供的存款服务进行存款，如果服务调用失败则进行重试。 异地银行存款操作不应该长久地出现异常而无法使用，因此一旦发现异常我们可以迅速的解决，消息中间件中异常服务自然会进行重试以保证事务的最终一致性。这种方式假设问题一定可以解决，在不到万不得已的情况下本地的取款服务一般不进行可逆操作。 在本地取款到异地存款两个服务调用之间，会存在一个真空期或者叫“不一致的窗口期”，这段时间相关现金不在任何一个账户，而只是在一个事务的中间状态，但是客户并不关心这个，只要在约定的时间保证事务最终的一致性即可。
聚合内事务
很多nosq数据库并不支持跨聚合事务，但在聚合内却能保证事务，所以在很多时候，我们可以把往常涉及到多个操作的组合合并到一个聚合内来操作，这样也算是一种分布式事务吧。虽然这些数据库并不支持跨聚合事务，但在一个聚合内却是支持事务的。
幂等操作 重复调用多次产生的业务结果与调用一次产生的业务结果相同，简单点讲所有提供的业务服务，不管是正向还是逆向的业务服务，都必须要支持重试。因为服务调用失败这种异常必须考虑到，不能因为服务的多次调用而导致业务数据的累计增加或减少。 关于是否需要补偿的问题 在这里我们谈的是多个跨系统的业务服务组合成一个分布式事务，因此在对事务进行补偿的时候必须要考虑客户需要的是否一定是最终一致性。客户对中间阶段出现的不一致的承受度是如何的。 在上面的例子来看，如果采用事务补偿机制，基本可以是做到准实时的补偿，不会有太大的影响。而如果采用基于消息的最终一致性方式，则可能整个周期比较长，需要较长的时间才能给得到最终的一致性。比如周六转款，客户可能下周一才得到通知转账不成功而进行了回退，那么就必须要考虑客户是否能给忍受。
关于隔离性
如果要想实现实时的一致性，那么即使采用事务补偿机制也无法达到实时的一致性。很可能在两个服务调用之间，这时候前台对你正要操作的数据进行了其他操作。在这种情况下，我们就不得不考虑添加业务锁。
数据库表状态锁
即整个事务没有完整提交并成功前，第一个业务服务调用虽然持久化在数据库，但是仍然是一个中间状态，需要通过业务锁来标记，控制相关的业务操作和行为。但是在这种模式下无疑增加了整个分布式业务系统的复杂度。
总结
以上四种方案说得冠冕堂皇一点，都有各种所适合的场景。2pc或3pc算是一种及时一致，或者叫强一致，然而现实很多时候显然有很大的延后或者窗口期，再加上2pc或3pc还没法做到无状态，这些不适应性都使得阶段提交对于微服务而言显得并不是很适合。而补偿机制其实是对于传统ACID的一种模仿。这种模仿是可以做到一致性。而且还可以做到实时的或者叫强一致性。但，每个正向操作都有一个逆向操作，这无疑为我们编码带来了更多的成本。其实我们说的所谓“事务”，无非是为了保证像类似转账这样的事情不要出现不一致而已。而只要能实现这一目的的方案都算是所谓“事务”。比如像事件源这种消息驱动再加重试幂等的做法就可以保证正向操作的最终成功。在微服务下，事件源机制和聚合内事务是不错的选择。事件源的好处不仅仅是解耦等。更重要的是，他也是微服务分布式查询的一个大前提，也就是是CQRS的大前提。而聚合内事务也算是对分布式事务的一种nosql数据库层面的支持，这样可以分摊一部分我们在处理分布式事务的麻烦，把一部分的事务在数据库聚合内就可以解决掉了。
感谢知乎大侠及技术车队提供的观点！
