分布式事务,当遇上分布式事务时,有哪些思路去解决?

当应用系统从小到大,从简单到复杂,单体应用已经承载不了当前的压力时，不可避免的需要对应用进行扩能

有钱的土豪公司可以升级硬件直到没钱或升无可升,没钱的只能升级软件

升级软件方法之一就是SOA或微服务啥的，都是走的服务/资源拆分这条路子，拆分过程中不可避免的会遇到分布式事务，甚至有些类型的应用在一开始就需要与外部服务交互，产生分布式服务事务问题

什么是分布式事务,就是多个服务点相同时刻数据的一致性问题。。。。请百度

下面就是几个解决分布式事务问题的思路或方法:

1.首先当然是尽可能避免分布式事务,当然这里说的不是不用分布式服务了，要不然本命题毫无意义,这里说的是，业务允许的话，尽量把相关业务聚合在一起(PS:避免问题和逃避问题不是一回事,避免是不让它发生,逃避是发生了不去解决，所以避免也属于解决方案)

2.努力保证，就是从代码层面尽量减小出现事务问题的概率，比如保存某些数据需要提交到多个数据源或多个服务，并且该保存具有事务性，那就放到最后，等所有逻辑什么的都做完了再一起提交保存；比如把容易出问题的放在前面等

3.最终一致性，不强求所有节点同一时刻数据一定要一致，只需要保证最终状态一致，比如事务补偿机制。举个例子：应用中涉及到微信支付,用户在自己的应用中发起支付后，调用微信，微信支付成功时，应用可能还处于支付中状态，这时同一个用户同一时刻的支付行为在应用和微信2方就处于不一致的状态，但是微信会发起支付成功的通知(事务补偿)通知应用修改支付状态，这就保证了最终一致性。当然在这个不一致的过程中，不能发生其他的状态转移，否则问题会更复杂。

  CAP理论中一般采用AP方式，也是放弃强一致，使用最终一致

4.2阶段提交,基于XA协议的2阶段,3阶段提交,有点类似于第二种方法的思路，就是应用先做好提交准备，再由事务管理器一起提交，涉及到资源管理，事务管理等多个角色，其实我也没用过，。。。。。百度吧。不过这种方案按我的理解，也不是保证能完全一致，而是减少了事务问题发生的概率而已，因为在提交过程中极端情况下也存在一个提交完了，另一个证准备执行保存的时候断网，断电什么的可能性。

5.还有一种paxos的一致性算法，采用少数服从多数的选举算法来确定数据的值。。。。

6.也可以利用zookeeper等服务，实现分布式事务监控，举个简单但不一定恰当的例子，比如确定某个分布式事务行为需要三个提交，每次把数据提交在zookeeper上并为该事务行为建立一个子节点，并判断是否已经达到了3个节点，已经达到则由这次提交来通知监控zk事务的应用（这个应用可以用来随时监控是否达到提交标准）实际提交，其实也有点类似于2阶段提交的方式。。。。

可能还有其他的方案，以后学习到再补充。。。。！