就在昨天，阿里分布式事務框架gts開源了乙個免費社群版fescar，看到了這個訊息內心非常的激動。在微服務系統中，分布式事務一直是痛點，也是難點。社群裡也有一些開源的分布式解決方案的框架，比如bytetcc、lcn，但是這些框架沒有乙個權威的組織在維護，或多或少大家都有點不敢用。阿里開源的分布式事務解決框架fescar會不會一統分布式事務江湖，大家拭目以待。
什麼是fescar？
fescar是一種分布式事務解決方案，具有高效能和易用性的微服務架構。
微服務中的分布式事務問題
在傳統的單體應用程式中，假設我們的業務由3個模組構成，分為庫存、訂單、賬戶模組。 他們使用同乙個單個本地資料來源。
本地事務可以保證資料的一致性。
微服務架構發生了變化。提到的3個模組設計為3個不同資料來源之上的3個服務（每個服務單獨的資料庫）。 本地事務能夠保證每個服務中的資料一致性。
但是在分布式微服務系統總共，整個業務邏輯的一致性如何保證呢？
fescar是怎麼解決上面提出的問題？
fescar為上述問題即分布式事務問題，提供了解決方案。
首先，如何定義分布式事務？
分布式事務是乙個全域性事務，由一批branch transation組成，通常branch transation只是本地事務。
在fesacr專案中有3個基本元件：
事務協調員（tc）：維護全域性和分支事務的狀態，推動全域性提交或回滾。
事務管理者（tm）：定義全域性事務的範圍：開始全域性事務，提交或回滾全域性事務。
資源管理器（rm）：管理分支事務處理的資源，與tc通訊以註冊分支事務和報告分支事務的狀態，並驅動分支事務提交或回滾。
fescar管理分布式事務的典型生命週期：
tm要求tc開始新的全域性事務。 tc生成表示全域性事務的xid。
xid通過微服務的呼叫鏈傳播。
rm將本地事務註冊為xid到tc的相應全域性事務的分支。
tm要求tc提交或回滾xid的相應全域性事務。
tc在xid的相應全域性事務下驅動所有分支事務以完成分支提交或rollbaking。
GTS分布式事務概念
gts 定義了一套事務框架以便描述分布式事務，在框架下支援不同事務模式執行。分布式事務包含以下 3 個核心元件 乙個典型的事務過程包括 tm 向 tc 申請開啟 begin 乙個全域性事務，全域性事務建立成功並生成乙個全域性唯一的 xid。xid 在微服務呼叫鏈路的上下文中傳播。rm 向 tc 註冊...
阿里開源GTS FESCAR分布式事務
2.進行測試時首先啟動 server專案server類的main方法，accountserviceimpl orderserviceimpl storageserviceimpl實現類的main方法，都是註冊到dubbo中作為各個服務，accountserviceimpl，storageservic...
分布式事務框架seata
seata at模式 at模式和xa模式一樣，都是乙個兩階段提交的事務模型，不過和xa相比，做了一些優化，這個官網著重講解了一下at的原理，之後開一節著重看下一at模式的實現原理。saga模式 另外saga還提供了一下兩種補償恢復方式 saga的優勢 saga的實現方式 在以上支付下單的流程上乙個典...