分布式事務,當遇上分布式事務時,有哪些思路去解決?

當應用系統從小到大,從簡單到複雜,單體應用已經承載不了目前的壓力時，不可避免的需要對應用進行擴能

有錢的土豪公司可以更新硬體直到沒錢或升無可升,沒錢的隻能更新軟體

更新軟體方法之一就是SOA或微服務啥的，都是走的服務/資源拆分這條路子，拆分過程中不可避免的會遇到分布式事務，甚至有些類型的應用在一開始就需要與外部服務互動，産生分布式服務事務問題

什麼是分布式事務,就是多個服務點相同時刻資料的一緻性問題。。。。請百度

下面就是幾個解決分布式事務問題的思路或方法:

1.首先當然是盡可能避免分布式事務,當然這裡說的不是不用分布式服務了，要不然本命題毫無意義,這裡說的是，業務允許的話，盡量把相關業務聚合在一起(PS:避免問題和逃避問題不是一回事,避免是不讓它發生,逃避是發生了不去解決，是以避免也屬于解決方案)

2.努力保證，就是從代碼層面盡量減小出現事務問題的機率，比如儲存某些資料需要送出到多個資料源或多個服務，并且該儲存具有事務性，那就放到最後，等所有邏輯什麼的都做完了再一起送出儲存；比如把容易出問題的放在前面等

3.最終一緻性，不強求所有節點同一時刻資料一定要一緻，隻需要保證最終狀态一緻，比如事務補償機制。舉個例子：應用中涉及到微信支付,使用者在自己的應用中發起支付後，調用微信，微信支付成功時，應用可能還處于支付中狀态，這時同一個使用者同一時刻的支付行為在應用和微信2方就處于不一緻的狀态，但是微信會發起支付成功的通知(事務補償)通知應用修改支付狀态，這就保證了最終一緻性。當然在這個不一緻的過程中，不能發生其他的狀态轉移，否則問題會更複雜。

  CAP理論中一般采用AP方式，也是放棄強一緻，使用最終一緻

4.2階段送出,基于XA協定的2階段,3階段送出,有點類似于第二種方法的思路，就是應用先做好送出準備，再由事務管理器一起送出，涉及到資源管理，事務管理等多個角色，其實我也沒用過，。。。。。百度吧。不過這種方案按我的了解，也不是保證能完全一緻，而是減少了事務問題發生的機率而已，因為在送出過程中極端情況下也存在一個送出完了，另一個證準備執行儲存的時候斷網，斷電什麼的可能性。

5.還有一種paxos的一緻性算法，采用少數服從多數的選舉算法來确定資料的值。。。。

6.也可以利用zookeeper等服務，實作分布式事務監控，舉個簡單但不一定恰當的例子，比如确定某個分布式事務行為需要三個送出，每次把資料送出在zookeeper上并為該事務行為建立一個子節點，并判斷是否已經達到了3個節點，已經達到則由這次送出來通知監控zk事務的應用（這個應用可以用來随時監控是否達到送出标準）實際送出，其實也有點類似于2階段送出的方式。。。。

可能還有其他的方案，以後學習到再補充。。。。！