廣為人知的阿里分布式事務解決方案：gts（global transaction service），已正式推出開源版本，取名為「fescar」，希望幫助業界解決微服務架構下的分布式事務問題，今天我們一起來深入了解。
另一方面，引入分布式事務支援的業務應該基本保持在同一量級上的效能表現，不能因為事務機制顯著拖慢業務。
高效能：引入分布式事務的保障，必然會有額外的開銷，引起效能的下降。我們希望把分布式事務引入的效能損耗降到非常低的水平，讓應用不因為分布式事務的引入導致業務的可用性受影響。
受協議本身的約束，事務資源的鎖定周期長。長週期的資源鎖定從業務層面來看，往往是不必要的，而因為事務資源的管理器是資料庫本身，應用層無法插手。這樣形成的局面就是，基於 xa 的應用往往效能會比較差，而且很難優化。
已經落地的基於 xa 的分布式解決方案，都依託於重量級的應用伺服器（tuxedo/weblogic/websphere 等)，這是不適用於微服務架構的。
tccsaga
transaction manager (tm)：控制全域性事務的邊界，負責開啟乙個全域性事務，並最終發起全域性提交或全域性回滾的決議。
resource manager (rm)：控制分支事務，負責分支註冊、狀態匯報，並接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。
xid 在微服務呼叫鏈路的上下文中傳播。
rm 向 tc 註冊分支事務，將其納入 xid 對應全域性事務的管轄。
tm 向 tc 發起針對 xid 的全域性提交或回滾決議。
tc 排程 xid 下管轄的全部分支事務完成提交或回滾請求。
propagation_supports：預設支援
propagation_mandatory：應用通過 api 來實現
propagation_requires_new：應用通過 api 來實現
propagation_not_supported：應用通過 api 來實現
propagation_never：應用通過 api 來實現
propagation_required_nested：不支援
狀態上報：在分支事務的資料操作完成後，需要向事務協調器上報其執行結果。
分支提交：響應協調器發出的分支事務提交的請求，完成分支提交。
分支回滾：響應協調器發出的分支事務回滾的請求，完成分支回滾。
對不同微服務框架的支援，開發者可以參考 dubbo 的實現。
對 mq、nosql 的支援，開發者可以參考 tcc 的實現。
配置和服務註冊發現：開發者通過少量的工作可以接入任何可以提供這類服務的框架。
當然，非 藍色 的部分也非常歡迎社群參與進來，貢獻更優的解決方案。
另外，xa 作為分布式事務的標準，是乙個完備的分布式事務解決方案不可或缺的，遠景的規劃中，我們一定需要把 xa 的支援加入進來。
資料庫支援: mysql
基於 spring aop 的 annotation
事務協調器: 單機版本
mt 模式
支援 tcc 模式事務的適配
動態配置和服務發現
事務協調器: 高可用集群版本
控制台: 監控/部署/公升級/擴縮容
不依賴 spring aop 的 annotation
熱點資料的優化處理機制
rocketmq 事務訊息納入全域性事務管理
nosql 納入全域性事務管理的適配機制
支援 hbase
支援 redis
阿里開源微服務架構分布式事務解決方案 fescar
fescar fast easy commit and rollback 是乙個用於微服務架構的分布式事務解決方案，它的特點是高效能且易於使用，旨在實現簡單並快速的事務提交與回滾。微服務架構中的分布式事務問題 從傳統的單體應用說起，假設乙個單體應用的業務由 3 個模組構成，三者使用單個本地資料來源。...
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...