1024開源首發 | 金融級分佈式事務框架 TXLE

開源背景

在 2017 年和 2018 年的 10 月 24 日，愛可生開源社區出品了 MySQL 分佈式中間件 DBLE 和數據複製產品 DTLE。時隔一年，DBLE 和 DTLE 在社區積累了更多的設計經驗和用戶反饋，有更多的企業和用戶在生產環境中使用它們，實現了產品的快速迭代。
目前，隨着微服務架構普遍被接受，企業對如何在微服務分佈式架構下，實現數據一致性要求也愈來愈高；TXLE 基於 Saga 模式，實現了分佈式架構下的全局事務框架，爲數據提供最終一致性；同時貼合金融業務場景設計了服務降級，差錯平臺對接等金融級功能。
這次開源 TXLE，是延續社區的開源傳統，每一年一款開源產品。爲豐富 MySQL 開源生態添磚加瓦，並但願能切實解決更多企業和用戶在金融場景下有關事務一致性的問題。

常見一致性保障手段

兩階段提交

XA 協議最先的分佈式事務模型是由 X/Open 國際聯盟提出的 X/Open Distributed Transaction Processing（DTP）模型，簡稱 XA 協議。
基於 XA 協議實現的分佈式事務對業務侵入很小。它最大的優點就是對使用方透明，用戶能夠像使用本地事務同樣使用基於 XA 協議的分佈式事務。XA 協議可以嚴格保障事務 ACID 特性。
嚴格保障事務 ACID 特性是一把雙刃劍。事務執行在過程當中須要將所需資源所有鎖定，它更加適用於執行時間肯定的短事務。對於長事務來講，整個事務進行期間對數據的獨佔，將致使對熱點數據依賴的業務系統併發性能衰退明顯。所以，在高併發的性能至上場景中，基於 XA 協議兩階段提交類型的分佈式事務並非最佳選擇。

柔性事務

若是將實現了 ACID 的事務要素的事務稱爲剛性事務的話，那麼基於 BASE 事務要素的事務則稱爲柔性事務。BASE 是基本可用、柔性狀態和最終一致性這 3 個要素的縮寫。
在 ACID 事務中對一致性和隔離性的要求很高，在事務執行過程當中，必須將全部的資源佔用。柔性事務的理念則是經過業務邏輯將互斥鎖操做從資源層面上移至業務層面。經過放寬對強一致性和隔離性的要求，只要求當整個事務最終結束的時候，數據是一致的。而在事務執行期間，任何讀取操做獲得的數據都有可能被改變。這種弱一致性的設計能夠用來換取系統吞吐量的提高。Saga 就是一種柔性事務實現模式。

（本文中，兩階段提交 和 柔性事務 段落部分引用文章連接： https://www.infoq.cn/article/...）

TXLE的架構

TXLE是一款基於 Saga 模式的開源分佈式事務框架，主要解決分佈式架構下的數據最終一致性。

• txle Agent：txle 在業務端的代理，主要經過對業務的攔截來生成全局事務和子事務，並將相關信息上報至 txle 服務端。
• txle Server：txle 的服務端，主要接收 txle agent 上報的全局事務和子事務信息，並對相關信息進行管理，在發生異常時，對相應的子事務進行協調。
• txle Server Cluster：系統引入 Consul 來保證 txle 服務端的高可用性，以及動態主從切換。
• txle Storage：即 MySQL 數據庫實例，用於存儲全局事務和子事務相關日誌信息、待協調信息和相關係統配置等。

目前支持整合主流框架 SpringCloud、Dubbo 等；同時提供鏈路追蹤、消息中心、數據轉儲和監控平臺等相關組件，以便保證 txle 服務可以更好地對外提供服務。另外還提供服務降級功能，差錯平臺等金融級屬性，以便在框架遇到嚴重故障時，還能保證主業務的正常運行。

TXLE的特性

• 支持 Docker 快速部署。
• 多種手段保證數據最終一致性。
• 高性能。單個事務分支對業務的性能影響在 2ms 左右。
• 低侵入。最少 2 個註解便可。
• 支持服務降級。發生不可抗拒因素時，也能保證主業務正常運行。
• 支持差錯處理，對接差錯平臺。
• 支持超時和重試機制。

項目地址

https://github.com/actiontech...

文檔地址

https://github.com/actiontech...

QQ羣

TXLE 官方 QQ 社區交流羣：696990638