一、前言

      隨著專案逐步以微服務開發為趨勢，逐漸呈現一個服務對應一個數據庫。從中產生了分散式事務的問題：一個操作先後呼叫不同的服務，要保證服務間的事務一致性，這就是分散式事務解決的問題。

      本次調研，根據github上star排名進行調研，主要調研了hmily和bytetcc兩種分散式事務框架。

二、選型原則

      本次調研主要是根據CAP和BASE理論進行，主要要保證資料的可用性、分割槽容錯性、最終一致性。

三、調研框架介紹

hmily介紹

      Hmily是由碧桂園工程師開發，高效能非同步分散式事務TCC框架。

特點：
1、 採用disruptor框架進行事務日誌的非同步讀寫，與RPC框架的效能毫無差別。
2、 RPC框架支援 : dubbo,motan,springcloud。
3、 支援巢狀事務(Nested transaction support).
4、 採用disruptor框架進行事務日誌的非同步讀寫，與RPC框架的效能毫無差別。
5、 支援SpringBoot-starter 專案啟動，使用簡單。
6、 本地事務儲存支援 : redis,mongodb,zookeeper,file,mysql。
7、 事務日誌序列化支援 ：java，hessian，kryo，protostuff。
8、 採用Aspect AOP 切面思想與Spring無縫整合，天然支援叢集。
9、 內建經典的分散式事務場景demo工程，並有swagger-ui視覺化介面可以快速體驗。
10、 非同步confirm 和 cancel，保證資料一致性
11、 使用Guava Cache

Bytetcc介紹

      Bytetcc是由北京新奧集團工程師開發，是一個相容JTA規範的基於TCC機制的分散式事務管理器。目前開發到了第五版，穩定版本為第四版，本次調研為第四版（0.4.x）。

特點：
1、支援Spring容器的宣告式事務管理；
2、支援普通事務、TCC事務、saga事務等事務機制；
3、支援多資料來源、跨應用、跨伺服器等分散式事務場景；
4、支援長事務；
5、支援dubbo服務框架；
6、支援spring cloud；

四、壓測機器情況說明

壓測機

• Windows 10 企業版
• 16GB
• Jmeter

伺服器

五、壓測報告

hmily壓測報告

正常執行

      測試結果分析：測試結果發現，吞吐量比較高，但是hmily存在優化的地方，當前版本非同步執行confirm和cancel的速度比較慢，且在高併發情況下存在資料不一致問題：

      例如：
      一共執行10w條資料，目標結果：庫存-10w ， 賬戶-10w。但是最終執行結果：庫存和賬戶的剩餘量不一樣。不能保證資料的最終一致性。

      Cpu：

      DB cpu：

帶回滾操作執行

      Cpu：

      DB cpu：

Bytetcc 壓測報告

正常執行

      測試結果分析：吞吐量比較低，可以保證資料的最終一致性。比較穩定。

      Cpu：

DB cpu：

帶回滾操作執行

      Cpu：

      DB cpu：

六、小結

      小編只是通過Jmeter對兩個比較火的分散式事務框架進行了壓測，其中的業務邏輯是一樣的，效能也是有不同的。

      測試的程式碼地址：