一、前言
隨着項目逐步以微服務開發爲趨勢，逐漸呈現一個服務對應一個數據庫。從中產生了分佈式事務的問題：一個操作先後調用不同的服務，要保證服務間的事務一致性，這就是分佈式事務解決的問題。
本次調研，根據github上star排名進行調研，主要調研了hmily和bytetcc兩種分佈式事務框架。
二、選型原則
本次調研主要是根據CAP和BASE理論進行，主要要保證數據的可用性、分區容錯性、最終一致性。
三、調研框架介紹
hmily介紹
Hmily是由碧桂園工程師開發，高性能異步分佈式事務TCC框架。
Github地址：https://github.com/yu199195/hmily
特點：
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）。
GitHub地址：https://github.com/liuyangming/ByteTCC
特點：
1、支持Spring容器的聲明式事務管理；
2、支持普通事務、TCC事務、saga事務等事務機制；
3、支持多數據源、跨應用、跨服務器等分佈式事務場景；
4、支持長事務；
5、支持dubbo服務框架；
6、支持spring cloud；
四、壓測機器情況說明
壓測機
- Windows 10 企業版
- 16GB
- Jmeter
服務器
| 服務器cpu | 服務器內存 | 服務器網絡 | 壓測機cpu | 服務器cpu配置 | 服務器內存配置 | rds的cpu情況,可能多個 | redis的cpu情況,可能多個 |
|---|---|---|---|---|---|---|---|
| 4 | 16 | 公司內網 | 4 | 4核 | 4G | 4 | 沒有使用 |
五、壓測報告
hmily壓測報告
正常執行
| 接口 | 總數 | 平均響應時間 | 中間數 | 90% | 95% | 99% | 最小響應時間 | 最大響應時間 | 錯誤率 | 吞吐量 | 每秒接受消息 | 每秒發送發送消息 | 線程數 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Pay | 500000 | 225 | 215 | 347 | 394 | 513 | 13 | 1374 | 0 | 438.7 | 51.41 | 87.82 | 100 |
測試結果分析：測試結果發現，吞吐量比較高，但是hmily存在優化的地方，當前版本異步執行confirm和cancel的速度比較慢，且在高併發情況下存在數據不一致問題：
例如：
一共執行10w條數據，目標結果：庫存-10w ， 賬戶-10w。但是最終執行結果：庫存和賬戶的剩餘量不一樣。不能保證數據的最終一致性。
Cpu：
DB cpu：
帶回滾操作執行
| 接口 | 總數 | 平均響應時間 | 中間數 | 90% | 95% | 99% | 最小響應時間 | 最大響應時間 | 錯誤率 | 吞吐量 | 每秒接受消息 | 每秒發送發送消息 | 線程數 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Pay | 200000 | 1573 | 1384 | 2703 | 3246 | 5815 | 48 | 11596 | 0 | 62.2 | 32.02 | 12.45 | 100 |
Cpu：
DB cpu：
Bytetcc 壓測報告
正常執行
| 接口 | 總數 | 平均響應時間 | 中間數 | 90% | 95% | 99% | 最小響應時間 | 最大響應時間 | 錯誤率 | 吞吐量 | 每秒接受消息 | 每秒發送發送消息 | 線程數 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Pay | 500000 | 1197 | 1180 | 1534 | 1652 | 1900 | 85 | 2953 | 0 | 106.9 | 14.43 | 16.71 | 100 |
測試結果分析：吞吐量比較低，可以保證數據的最終一致性。比較穩定。
Cpu：
DB cpu：
帶回滾操作執行
| 接口 | 總數 | 平均響應時間 | 中間數 | 90% | 95% | 99% | 最小響應時間 | 最大響應時間 | 錯誤率 | 吞吐量 | 每秒接受消息 | 每秒發送發送消息 | 線程數 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Pay | 60000 | 4006 | 3556 | 4491 | 4973 | 21972 | 100 | 10012 | 0 | 48.6 | 9.1 | 9.64 | 100 |
Cpu：
DB cpu：
六、小結
小編只是通過Jmeter對兩個比較火的分佈式事務框架進行了壓測，其中的業務邏輯是一樣的，性能也是有不同的。
測試的代碼地址：
hmily：https://github.com/AresKingCarry/hmilyDemo
Bytetcc：https://github.com/AresKingCarry/ByteTccDemo