微服務架構流行的今天，一次交易需要跨越多個“服務”、多個資料庫來實作，傳統的技術手段，已經無法應對和滿足微服務情況下這些複雜的場景了。針對微服務下的交易業務如何保障資料一緻性，本文盡量做到理論結合實際，将我們在實際産品中用到的分布式事務實作機制，和大家扒一扒，希望能幫助到讀者。
談到分布式事務，必須先把”cap"拿出來說說事......，當然還有”base"......
從架構的角度來看，業務拆分（資料分區）、資料一緻性、性能（可用性）永遠是個平衡的藝術：
1）在微服務架構下，為了獲得更高的性能與靈活性，将業務應用拆分為多個，交易跨多個微服務編排，資料一緻性的問題産生；
2）為了解決資料一緻性問題，需要采用不同的事務機制來保障，這又會産生性能（可用性）問題；
在計算機世界裡，為了解決一件事情，另外的問題就會接踵而至，從另一個層面印證了it架構永遠是一種平衡的藝術。
“base”其核心思想是根據業務特點，采用适當的方式來使系統達到最終一緻性(eventualconsistency)；在網際網路領域，通常需要犧牲強一緻性來換取系統的高可用性，隻需要保證資料的“最終一緻”，隻是這個最終時間需要在使用者可以接受的範圍内；但在金融相關的交易領域，仍然需要采用強一緻性的方式來保障交易的準确性與可靠性。
分布式事務介紹
接下來為大家介紹業界常見的事務處理模式，包括兩階段送出、三階段送出、sagas長事務、補償模式、可靠事件模式（本地事件表、外部事件表）、可靠事件模式（非事務消息、事務消息）、tcc等。不同的事務模型支援不同的資料一緻性。如果讀者對這幾種分布式事務比較熟悉，可以直接參考下圖并結合自身業務需求選擇合适的事務模型。
一、兩階段送出、三階段送出
這種分布式事務解決方案目前在各種技術平台上已經比較成熟：javaee架構下面的jta事務（各應用伺服器均提供了實作，tomcat除外）。
目前兩階段送出、三階段送出存在如下的局限性，并不适合在微服務架構體系下使用：
1）所有的操作必須是事務性資源（比如資料庫、消息隊列、ejb元件等），存在使用局限性（微服務架構下多數使用http協定），比較适合傳統的單體應用；
2）由于是強一緻性，資源需要在事務内部等待，性能影響較大，吞吐率不高，不适合高并發與高性能的業務場景；
二、sagas長事務
在sagas事務模型中，一個長事務是由一個預先定義好執行順序的子事務集合和他們對應的補償子事務集合組成的。典型的一個完整的交易由t1、t2、......、tn等多個業務活動組成，每個業務活動可以是本地操作、或者是遠端操作，所有的業務活動在sagas事務下要麼全部成功，要麼全部復原，不存在中間狀态。
sagas事務模型的實作機制：
1）每個業務活動都是一個原子操作；
2）每個業務活動均提供正反操作；
3）任何一個業務活動發生錯誤，按照執行的反順序，實時執行反操作，進行事務復原；
4）復原失敗情況下，需要記錄待沖正事務日志，通過重試政策進行重試；
5）沖正重試依然失敗的場景，提供定時沖正伺服器，對復原失敗的業務進行定時沖正；
6）定時沖正依然失敗的業務，等待人工幹預；
sagas長事務模型支援對資料一緻性要求比較高的場景比較适用，由于采用了補償的機制，每個原子操作都是先執行任務，避免了長時間的資源鎖定，能做到實時釋放資源，性能相對有保障。
sagas長事務方式如果由業務去實作，複雜度與難度并存。在我們實際使用過程中，開發了一套支援sagas事務模型的架構來支撐業務快速傳遞。
開發人員：業務隻需要進行交易編排，每個原子操作提供正反交易；
配置人員：可以針對異常類型設定事務復原政策（哪些異常納入事務管理、哪些異常不納入事務管理）；每個原子操作的流水是否持久化（為了不同性能可以支援緩存、db、以及擴充其它持久化方式）；以及沖正選項配置（重試次數、逾時時間、是否實時沖正、定時沖正等）；
sagas事務架構：提供事務保障機制，負責原子操作的流水落地，原子操作的執行順序，提供實時沖正、定時沖正、事務攔截器等基礎能力；
sagas架構的核心是ibusinessactivity、iatomicaction。ibusinessactivity完成原子活動的enlist()、delist()、prepare()、commit()、rollback()等操作；iatomicaction主要完成對狀态上下文、正反操作執行。
限于文章篇幅，本文不對具體實作做詳述；後面找時間可以詳細介紹基于sagas長事務模型具體的實作架構。
sagas長事務需要交易提供反操作，支援事務的強一緻性，由于沒有在整個事務周期内鎖定資源，對性能影響較小，适合對資料要求比較高的場景中使用。
三、補償模式