分布式計算是如何控制事務的？

事務的管理不應該屬于Dubbo框架， Dubbo只需實現可被事務管理即可， 像JDBC和JMS都是可被事務管理的分布式資源， Dubbo只要實現相同的可被事務管理的行為，比如可以回滾， 其它事務的調度，都應該由專門的事務管理器實現。 在Java中，分布式事務主要的規范是JTA/XA， 其中：JTA是Java的事務管理器規范， XA是工業標準的X/Open CAE規范，可被兩階段提交及回滾的事務資源定義， 比如某數據庫實現了XA規范，則不管是JTA，還是MSDTC，都可以基于同樣的行為對該數據庫進行事務處理。

首先是不建議采用XA兩階段提交方式去處理分布式事務，要知道要能夠支持XA分布式事務，必須是要實現XA規范才可以，而Service本身是無狀態的，如果這樣去做了等于是把Service內部的東西暴露了出去。對于分布式事務最好的方式還是事務補償或者BASE基于消息的最終一致性。

可以設想一個最簡單的分布式事務場景，對于跨銀行的轉賬操作，該操作涉及到調用兩個異地的Service服務，一個是本地提供的取款服務，一個是目標銀行提供的存款服務，該兩個服務本身無狀態且獨立，構成一個完整的事務。對于事務的處理初步分析: 事務補償機制 事務補償即在事務鏈中的任何一個正向事務操作，都必須存在一個完全符合回滾規則的可逆事務。如果是一個完整的事務鏈，則必須事務鏈中的每一個業務服務或操作都有對應的可逆服務。對于Service服務本身無狀態，也不容易實現前面討論過的通過DTC或XA機制實現的跨應用和資源的事務管理，建立跨資源的事務上下文。因此也較難以實現真正的預提交和正式提交的分離。

在這種情況下以上面例子來說，首先調用取款服務，完全調用成功并返回，數據已經持久化。然后調用異地的存款服務，如果也調用成功，則本身無任何問題。如果調用失敗，則需要調用本地注冊的逆向服務（本地存款服務），如果本地存款服務調用失敗，則必須考慮重試，如果約定重試次數仍然不成功，則必須log到完整的不一致信息。也可以是將本地存款服務作為消息發送到消息中間件，由消息中間件接管后續操作。 在上面方式中可以看到需要手工編寫大量的代碼來處理以保證事務的完整性，我們可以考慮實現一個通用的事務管理器，實現事務鏈和事務上下文的管理。對于事務鏈上的任何一個服務正向和逆向操作均在事務管理和協同器上注冊，由事務管理器接管所有的事務補償和回滾操作。

基于消息的最終一致性 在這里首先要回答的是我們需要時實時一致性還是最終一致性的問題，如果需要的是最終一致性，那么BASE策略中的基于消息的最終一致性是比較好的解決方案。這種方案真正實現了兩個服務的真正解耦，解耦的關鍵就是異步消息和消息持久化機制。 還是以上面的例子來看。對于轉賬操作，原有的兩個服務調用變化為第一步調用本地的取款服務，第二步發送異地取款的異步消息到消息中間件。如果第二步在本地，則保證事務的完整性基本無任何問題，即本身就是本地事務的管理機制。只要兩個操作都成功即可以返回客戶成功。

由于解耦，我們看到客戶得到成功返回的時候，如果是上面一種情況則異地卡馬上就能查詢賬戶存款增加。而第二種情況則不一定，因為本身是一種異步處理機制。消息中間件得到消息后會去對消息解析，然后調用異地銀行提供的存款服務進行存款，如果服務調用失敗則進行重試。

異地銀行存款操作不應該長久地出現異常而無法使用，因此一旦發現異常我們可以迅速的解決，消息中間件中異常服務自然會進行重試以保證事務的最終一致性。這種方式假設問題一定可以解決，在不到萬不得已的情況下本地的取款服務一般不進行可逆操作。 在本地取款到異地存款兩個服務調用之間，會存在一個真空期，這段時間相關現金不在任何一個賬戶，而只是在一個事務的中間狀態，但是客戶并不關心這個，只要在約定的時間保證事務最終的一致性即可。

關于冪等操作的問題 重復調用多次產生的業務結果與調用一次產生的業務結果相同，簡單點講所有提供的業務服務，不管是正向還是逆向的業務服務，都必須要支持重試。因為服務調用失敗這種異常必須考慮到，不能因為服務的多次調用而導致業務數據的累計增加或減少。 關于是否可以補償的問題 在這里我們談的是多個跨系統的業務服務組合成一個分布式事務，因此在對事務進行補償的時候必須要考慮客戶需要的是否一定是最終一致性?？蛻魧χ虚g階段出現的不一致的承受度是如何的。 3

在上面的例子來看，如果采用事務補償機制，基本可以是做到準實時的補償，不會有太大的影響。而如果采用基于消息的最終一致性方式，則可能整個周期比較長，需要較長的時間才能給得到最終的一致性。比如周六轉款，客戶可能下周一才得到通知轉賬不成功而進行了回退，那么就必須要考慮客戶是否能給忍受。

其次對于前面討論，如果真正需要的是實時的一致性，那么即使采用事務補償機制，也無法達到實時的一致性。即很可能在兩個業務服務調用中間，客戶前臺業務操作對持久化的數據進行了其它額外的操作。在這種模式下，我們不得不考慮需要在數據庫表增加業務狀態鎖的問題，即整個事務沒有完整提交并成功前，第一個業務服務調用雖然持久化在數據庫，但是仍然是一個中間狀態，需要通過業務鎖來標記，控制相關的業務操作和行為。但是在這種模式下無疑增加了整個分布式業務系統的復雜度。