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

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

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

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

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

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

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

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

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

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

4.2阶段提交,基于XA协议