微服務的搭建
微服務中咱們把業務的能力進行了抽象，實際的業務中咱們須要用到不一樣的服務的能力，而且咱們處理的業務須要事務的一致性，避免出現數據的紊亂，那麼咱們就須要對分佈式的微服務進行一致性事務的處理。下面是我本身總結的幾種方案。sql
分佈式事務解決的方案
1、（XA）兩階段方案
一、先提交每個（這個是加鎖）異步
二、確認資源，確認每個RM是否都成功了，判斷是否要提交仍是要回滾分佈式
2、TCC（try-confirm-cancle）兩階段補償性方案
一、先提交狀態爲中間狀態（數據表更改成更新中，而不是加鎖）微服務
二、確認資源，確認每個RM是否都成功了，都成功了，更新sql的狀態，不然回滾spa
TCC相比於XA的優勢
一、TCC是更新數據爲中間狀態，而兩階段方案是加鎖server
二、TCC可以對分佈式事務中的各個資源進行分別鎖定，分別提交與釋放，例如，假設有AB 兩個操做，假設A操做耗時短，那麼A就能較快的完成自身的try-confirm-cancel流程，釋 放資源，無需等待B操做。若是過後出現問題, 追加執行補償性事務便可中間件
三、TCC是綁定在各個子業務上的(除了cancle中的全局回滾操做)，也就是各服務之間能夠 在必定程度上」異步並行」執行事務
適用的場景：
一、嚴格一致性資源
二、執行時間短同步
三、實時性要求高
3、異步確認性
經過將一系列同步的事務操做變爲基於消息執行異步操做，避免了分佈式事務中的同步阻塞 操做的影響。
須要額外說明的一點，就是事務消息投遞到MQ定閱方後，並不必定可以成功執行。
須要 MQ訂閱方主動給予消費反饋（ack）:
一、若是MQ訂閱方執行遠程事務成功，則給予消費成功的ACK,那麼MQ server能夠將事務 消息移除；
二、若是執行失敗，MQ Server須要對消息從新投遞，直至消費成功。
注意事項
一、消息中間件在系統中扮演一個重要的角色，全部的事務消息都須要經過它來傳達，因此 消息中間件也須要支持 HAC 來確保事務消息不丟失。
二、根據業務邏輯的具體實現不一樣，還可能須要對消息中間件增長消息不重複，不亂序等其 它要求。
適用場景
一、執行週期較長
二、實時行要求不高
例如
一、跨行轉帳/匯款業務（兩個服務分別在不一樣的銀行中）
二、退貨/退款業務
三、財務，帳單統計業務（先發送到消息中間件，而後進行批量記帳）
4、最大努力通知型
這是分佈式事務中要求最低的一種，也能夠經過消息中間件實現，與前面異步確保型操做不 同的一點是，在消息由MQ Server投遞到消費者以後，容許在達到最大重試次數以後正常 結束事務。
適用場景
交易結果消息的通知等。