分布式事務在Sharding-Sphere中的實現(xiàn)

1、 分布式事務在Sharding-Sphere中的實現(xiàn) from ShardingSphere官微講師簡介趙俊京東金融高級Java開發(fā)工程師多年互聯(lián)網開發(fā)經驗，熱愛開源技術，對分布式存儲有濃厚的興趣。熟悉ElasticSearch、HBase、Presto、Storm等離線和實時數據處理目前主要在Sharding-Sphere團隊負責分布式事務的開發(fā)分享大綱：分布式事務的使用場景 業(yè)界方法 Sharding-Sphere對分布式事務的支持 未來開發(fā)計劃分布式事務的使用場景01ACID一切從ACID開始說起。ACID是本地事務所具有的四大特征：Atomicity：原子性事務作為整體來執(zhí)行，要么全部

2、執(zhí)行，要么全不執(zhí)行。Consistency：一致性事務應確保數據從一個一致的狀態(tài)轉變?yōu)榱硪粋€一致的狀態(tài)。Isolation：隔離性多個事務并發(fā)執(zhí)行時，一個事務的執(zhí)行不應影響其他事務的執(zhí)行。Durability：持久性已提交的事務修改數據會被持久保持。關系型數據庫的本地事務完美的提供了對ACID的原生支持。但在分布式的場景下，它卻成為系統(tǒng)性能的桎梏。如何讓數據庫在分布式場景下滿足ACID的特性或找尋相應的替代方案，是本文將要闡述的話題。02CAP和Base理論對于互聯(lián)網應用而言，隨著訪問量和數據量的激增，傳統(tǒng)的單體架構模式將無法滿足業(yè)務的高速發(fā)展。這時，開發(fā)者需要把單體應用拆分為多個獨立的小應用

3、，把單個數據庫按照分片規(guī)則拆分為多個庫和多個表。數據拆分后，如何在多個數據庫節(jié)點間保證本地事務的ACID特性則成為一個技術難題，并且由此而衍生出了CAP和BASE經典理論。CAP理論指出，對于分布式的應用而言，不可能同時滿足C（一致性），A（可用性），P（分區(qū)容錯性），由于網絡分區(qū)是分布式應用的基本要素，因此開發(fā)者需要在C和A上做出平衡。由于C和A互斥性，其權衡的結果就是BASE理論。對于大部分的分布式應用而言，只要數據在規(guī)定的時間內達到最終一致性即可。我們可以把符合傳統(tǒng)的ACID叫做剛性事務，把滿足BASE理論的最終一致性事務叫做柔性事務。一味的追求強一致性，并非最佳方案。對于分布式應用來說

4、，剛柔并濟是更加合理的設計方案，即在本地服務中采用強一致事務，在跨系統(tǒng)調用中采用最終一致性。如何權衡系統(tǒng)的性能與一致性，是十分考驗架構師與開發(fā)者的設計功力的。業(yè)界方法具體到分布式事務的實現(xiàn)上，業(yè)界主要采用了XA協(xié)議的強一致規(guī)范以及柔性事務的最終一致規(guī)范。01XAXA是X/Open CAE Specification (Distributed Transaction Processing)模型中定義的TM（Transaction Manager）與RM（Resource Manager）之間進行通信的接口。Java中的javax.transaction.xa.XAResource定義了XA接口，

5、它依賴數據庫廠商對jdbc-driver的具體實現(xiàn)。mysql-connector-java-5.1.30的實現(xiàn)可參考：com.mysql.jdbc.jdbc2.optional.MysqlXAConnection。在XA規(guī)范中，數據庫充當RM角色，應用需要充當TM的角色，即生成全局的txId，調用XAResource接口，把多個本地事務協(xié)調為全局統(tǒng)一的分布式事務。一階段提交：弱XA弱XA通過去掉XA的Prepare階段，以達到減少資源鎖定范圍而提升并發(fā)性能的效果。典型的實現(xiàn)為在一個業(yè)務線程中，遍歷所有的數據庫連接，依次做commit或者rollback。弱XA同本地事務相比，性能損耗低，但在

6、事務提交的執(zhí)行過程中，若出現(xiàn)網絡故障、數據庫宕機等預期之外的異常，將會造成數據不一致，且無法進行回滾。基于弱XA的事務無需額外的實現(xiàn)成本，因此Sharding-Sphere默認支持。二階段提交：2PC二階段提交是XA的標準實現(xiàn)。它將分布式事務的提交拆分為2個階段：prepare和commit/rollback。開啟XA全局事務后，所有子事務會按照本地默認的隔離級別鎖定資源，并記錄undo和redo日志，然后由TM發(fā)起prepare投票，詢問所有的子事務是否可以進行提交：當所有子事務反饋的結果為“yes”時，TM再發(fā)起commit；若其中任何一個子事務反饋的結果為“no”，TM則發(fā)起rollba

7、ck；如果在prepare階段的反饋結果為yes，而commit的過程中出現(xiàn)宕機等異常時，則在節(jié)點服務重啟后，可根據XArecover再次進行commit補償，以保證數據的一致性。2PC模型中，在prepare階段需要等待所有參與子事務的反饋，因此可能造成數據庫資源鎖定時間過長，不適合并發(fā)高以及子事務生命周長較長的業(yè)務場景。Sharding-Sphere支持基于XA的強一致性事務解決方案，可以通過SPI注入不同的第三方組件作為事務管理器實現(xiàn)XA協(xié)議，如Atomikos和Narayana。02柔性事務柔性事務是對XA協(xié)議的妥協(xié)和補償，它通過對強一致性要求的降低，已達到降低數據庫資源鎖定時間的效果

8、。柔性事務的種類很多，可以通過各種不同的策略來權衡使用。一階段提交 + 補償 ：最大努力送達（BED）最大努力送達，是針對于弱XA的一種補償策略。它采用事務表記錄所有的事務操作SQL，如果子事務提交成功，將會刪除事務日志；如果執(zhí)行失敗，則會按照配置的重試次數，嘗試再次提交，即最大努力的進行提交，盡量保證數據的一致性，這里可以根據不同的業(yè)務場景，平衡C和A，采用同步重試或異步重試。這種策略的優(yōu)點是無鎖定資源時間，性能損耗小。缺點是嘗試多次提交失敗后，無法回滾，它僅適用于事務最終一定能夠成功的業(yè)務場景。因此BED是通過事務回滾功能上的妥協(xié)，來換取性能的提升。TCC： Try-Confirm-Can

9、celTCC模型是把鎖的粒度完全交給業(yè)務處理，它需要每個子事務業(yè)務都實現(xiàn)Try-Confirm/Cancel接口。Try:嘗試執(zhí)行業(yè)務；完成所有業(yè)務檢查（一致性）；預留必須業(yè)務資源（準隔離性）；Confirm:確認執(zhí)行業(yè)務；真正執(zhí)行業(yè)務，不作任何業(yè)務檢查；只使用Try階段預留的業(yè)務資源；Confirm操作滿足冪等性；Cancel:取消執(zhí)行業(yè)務；釋放Try階段預留的業(yè)務資源；Cancel操作滿足冪等性。這三個階段都會按本地事務的方式執(zhí)行，不同于XA的prepare，TCC無需將XA的投票期間的所有資源掛起，因此極大的提高了吞吐量。下面對TCC模式下，A賬戶往B賬戶匯款100元為例子，對業(yè)務的改造

10、進行詳細的分析：匯款服務和收款服務分別需要實現(xiàn)，Try-Confirm-Cancel接口，并在業(yè)務初始化階段將其注入到TCC事務管理器中。匯款服務Try：檢查A賬戶有效性，即查看A賬戶的狀態(tài)是否為“轉帳中”或者“凍結”；檢查A賬戶余額是否充足；從A賬戶中扣減100元，并將狀態(tài)置為“轉賬中”；預留扣減資源，將從A往B賬戶轉賬100元這個事件存入消息或者日志中；Confirm：不做任何操作；Cancel：A賬戶增加100元；從日志或者消息中，釋放扣減資源。收款服務Try：檢查B賬戶賬戶是否有效；Confirm：讀取日志或者消息，B賬戶增加100元；從日志或者消息中，釋放扣減資源；Cancel：不做

11、任何操作。由此可以看出，TCC模型對業(yè)務的侵入強，改造的難度大。消息驅動消息一致性方案是通過消息中間件保證上下游應用數據操作的一致性?；舅悸肥菍⒈镜夭僮骱桶l(fā)送消息放在一個事務中，下游應用向消息系統(tǒng)訂閱該消息，收到消息后執(zhí)行相應操作。本質上是依靠消息的重試機制，達到最終一致性。消息驅動的缺點是：耦合度高，需要在業(yè)務系統(tǒng)中引入MQ，導致系統(tǒng)復雜度增加。SAGASaga起源于1987年Hector & Kenneth發(fā)表的論文Sagas。參考地址：/andru/cs711/2002fa/reading/sagas.pdfSaga工作原理Saga模型把一個分布式事務拆分為多個本地事務，每個本地事務都

12、有相應的執(zhí)行模塊和補償模塊（ TCC中的Confirm和Cancel）。當Saga事務中任意一個本地事務出錯時，可以通過調用相關的補償方法恢復之前的事務，達到事務最終的一致性。當每個Saga子事務 T1, T2, , Tn 都有對應的補償定義 C1, C2, , Cn-1,那么Saga系統(tǒng)可以保證：子事務序列T1, T2, , Tn得以完成(最佳情況)；或者序列T1, T2, , Tj, Cj, , C2, C1, 0 j n, 得以完成。由于Saga模型中沒有Prepare階段，因此事務間不能保證隔離性，當多個Saga事務操作同一資源時，就會產生更新丟失、臟數據讀取等問題，這時需要在業(yè)務層控

13、制并發(fā)，例如：在應用層面加鎖；應用層面預先凍結資源。Saga恢復方式Saga支持向前和向后恢復：向后恢復：補償所有已完成的事務，如果任一子事務失敗；向前恢復：重試失敗的事務，假設每個子事務最終都會成功。顯然，向前恢復沒有必要提供補償事務，如果你的業(yè)務中，子事務（最終）總會成功，或補償事務難以定義或不可能，向前恢復更符合你的需求。理論上補償事務永不失敗，然而，在分布式世界中，服務器可能會宕機、網絡可能會失敗，甚至數據中心也可能會停電，這時需要提供故障恢復后回退的機制，比如人工干預?？偟膩碚f，TCC和MQ都是以服務為范圍進行分布式事務的處理，而XA、BED、SAGA則是以數據庫為范圍進行分布式處理

14、，我們更趨向于選擇后者，對于業(yè)務而言侵入小，改造的成本低。Sharding-Sphere對分布式事務的支持Sharding-Sphere是一套開源的分布式數據庫中間件解決方案組成的生態(tài)圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar這3款相互獨立的產品組成。它們均提供標準化的數據分片、讀寫分離、柔性事務和數據治理功能，可適用于如Java同構、異構語言、容器、云原生等各種多樣化的應用場景。項目地址：/sharding-sphere/sharding-sphere/Sharding-Sphere同時支持XA和柔性事務，它允許每次對數據庫的訪問，可以

15、自由選擇事務類型。分布式事務對業(yè)務操作完全透明，極大地降低了引入分布式事務的成本。01事務模型Sharding-Sphere事務管理器集成了XA和柔性事務模型：對于XA事務而言，采用SPI的方式讓弱XA、Atomikos、Narayana間保持互斥；對于柔性事務而言，根據每次連接中事務的類型，可以選擇獨立的事務管理器進行處理，每個事務管理器都會實現(xiàn)標準的ShardingTransaction接口，在TransactionEvent到來時，執(zhí)行對應的begin、commit、rollback操作。下面將Sharding-Sphere內部如何用事件驅動方式，將事務從分片主流程中解耦進行詳細說明：從

16、圖可以看出在Sharding-core在調用執(zhí)行引擎時，會根據SQL的種類產生事件進行分發(fā)。事務監(jiān)聽線程在收到符合要求的事件后，再調用對應的事務處理器進行處理。02Sharding-Proxy事務實現(xiàn)Sharding-Proxy是基于netty開發(fā)的數據庫中間代理層，實現(xiàn)了標準的MySQL協(xié)議，可以看做是一個實現(xiàn)了數據分片的數據庫。Sharding-Proxy已經實現(xiàn)了基于Atomikos的XA事務，為了保證所有的子事務都處于同一個線程之中，整個Proxy的線程模型進行了如下的調整：當開啟事務后，Proxy后端的SQL命令執(zhí)行引擎將采用一通道一線程的模式，此事務線程的生命周期同通道保持一致。事

17、務處理的具體過程與Proxy徹底解耦，即Proxy將發(fā)布事務類型的事件，然后Sharding-Sphere-TM根據傳入的事務消息，選擇具體的TM進行處理。壓測結果表明：XA事務的插入和更新的性能，基本上同跨庫的個數呈線性關系，查詢的性能基本不受影響，建議在并發(fā)量不大，每次事務涉及的庫在10個以內時，可以使用XA。Atomikos事務管理器原理分析Atomikos的事務管理器可以內嵌到業(yè)務進程中，當應用調用TransactionManager.begin時，將會創(chuàng)建本次XA事務，并且與當前線程關聯(lián)。同時Atomikos也對DataSource中的connection做了二次封裝，代理conne

18、ction中含有本次事務相關信息的狀態(tài)，并且攔截了connection的JDBC操作。在createStatement時，調用XAResource.start進行資源注冊；在close時，調用XAResource.end讓XA事務處于idel可提交狀態(tài)；在commit或rollback時，依次調用prepare和commit進行二階段提交。Sharding-Sphere的Saga事務實現(xiàn)Sharding-Sphere通過與Apache Service Comb的合作，將采用Service Comb的Saga事務引擎作為的分布式事務實現(xiàn)。Apache Service Comb是華為開源的微服務框

19、架，其中微服務事務處理框架分為集中式和分布式協(xié)調器。未來會在Sharding-Sphere內部集成Saga集中式協(xié)調器，支持同一線程內不同服務（本地）間的分布式事務。參考鏈接：/apache/incubator-servicecomb-sagaService Comb 集中式事務協(xié)調器集中式的協(xié)調器，包含了Saga調用請求接收、分析、執(zhí)行以及結果查詢的內容。任務代理模塊需要預先知道Saga事務調用關系圖，執(zhí)行模塊根據生成的調用圖產生調用任務，調用相關微服務服務接口。如果服務調用執(zhí)行出錯，會調用服務的相關的補償方法回滾。Saga執(zhí)行模塊通過分析請求的JSON數據，來構建一個調用關系圖。Shard

20、ing-Sphere是通過JSON描述Saga事務串行調用子事務或者并行調用子事務。關系調用圖被Saga實現(xiàn)中的任務運行模塊分解成為一個一個執(zhí)行任務，執(zhí)行任務由任務消費者獲取并生成相關的調用 （同時支持串行和并行調用）。Saga任務會根據執(zhí)行的情況向Saga Log中記錄對應的Saga事務的關鍵事件，并可以通過事件查看器查查詢執(zhí)行情況。Sharding-Sphere內嵌Saga事務管理器Saga以jar包的形式提供分布式事務治理能力。對Sharding-Sphere而言，confirm和cancel過程代表了子事務中的正常執(zhí)行SQL和逆向執(zhí)行SQL，（未來Sharding-Sphere將提供自

21、動生成逆向SQL的能力）。當啟用Saga柔性事務后，路由完成之后的物理數據源將開啟本地自動提交事務，每次confirm和cancel都會直接提交。在Sharding-Sphere內部，觸發(fā)SQL執(zhí)行引擎后，將會產生Saga事務事件，這時Sharding-Sphere事務監(jiān)聽器會注冊本次子事務的confirm和cancel至Saga事務管理器的隊列中；在業(yè)務線程觸發(fā)commit和rollback后，Saga事務管理器再根據子事務執(zhí)行的結果，判斷進行confirm重試或者cancel流程。未來計劃未來Sharding-Sphere將按照文中介紹的Sharding-Sphere-TM逐步完善整個事務

22、框架：弱XA事務 （已發(fā)布）基于Atomikos的XA事務（近期發(fā)布）基于Narayana的XA事務（規(guī)劃中）BED柔性事務（已發(fā)布）SAGA（開發(fā)中）TCC（規(guī)劃中）如果前面的分享太過冗長，那么千言萬語匯聚成一張表格，歡迎閱讀。未來，我們將不斷優(yōu)化當前的特性，陸續(xù)推出大家關注的柔性事務、數據治理等更多新特性。如果有什么想法、意見和建議，也歡迎留言交流，更歡迎加入到Sharding-Sphere的開源項目中：/sharding-sphere/sharding-sphere/sharding-sphere/sharding-sphere/Q&AQ1：基于XA的事物，可以應用到微服務架構中嗎？A1

23、：目前我們是把事務管理器內嵌到JVM進程中，對于并發(fā)量小，短事務的業(yè)務，可以用XA。Q2：對于各個事務框架開發(fā)計劃的先后順序是基本什么來確定的呢？A2：基于難易程度，所以我們把TCC放到了最后。Q3：支持多語言嗎？比如golang？A3：多語言可以用Sharding-Proxy。Q4：這次是Proxy實現(xiàn)分布式事務吧？我記得之前Sharding-JDBC有實現(xiàn)。A4：這次是整個SS的事務實現(xiàn)，包含Sharding-JDBC和Proxy，目前SJ的實現(xiàn)是弱XA和BED（最大努力送達），以后會增加SAGA和TCC。Q5：如果我只想用SS里的事務模塊，可以嗎？A5：SS是以事件驅動的方式進行的架構，未來事務模塊只負責事務相關的處理。Q6：SAGA不支持ACID中的I，咱們這邊怎么考慮的呢？A6：目前暫不支持隔離性，今后我們有增加I的規(guī)劃，其實所有的柔性事務都不支持I，TCC增加了Try階段，