DTM 與 SEATA 主要特性對比

DTM 與 SEATA 是分佈式事務領域兩個重要的開源框架，下面就兩個框架的主要特性進行對比，方便讀者更好的選擇適合自己的框架。

支持語言

dtm 從設計之初就考慮了多語言支持，目前已經有多個語言的 SDK，包括 Go、Java、PHP、Python、C#、Node。

dtm 在架構上面，就把 SDK 層做的很薄，把能夠在服務端完成的事情全部放到服務端，這樣能夠方便各個語言快捷的開發 SDK。通常一門語言某個模式的 SDK 實現也就幾十到一兩百行的代碼。

dtm 在接口設計上，也充分考慮了多語言支持。例如：

Seata 目前主要支持 Java，對 Java 生態的支持較完備，另外採用了註解方式的接口，對 Java 開發人員較友好。因爲它的 SDK，相對較重，裏面包含了大量的邏輯，想要在一門新語言中，實現 SDK，工作量非常大。他在非 Java 的語言中，看到有 seata-go，但目前還不是很成熟。

異常處理

異常問題這裏主要是指分佈式系統中 Network Delay 和 Process Pause 造成的亂序，需要應用處理重複請求、懸掛、空補償。這是一個非常棘手的問題，雖然每個分佈式事務框架都給出了業務實現建議，但是業務實現這個非常困難，很容易掉坑，並且難以測試，詳情可以參考子事務屏障自動處理

dtm 首創了子事務屏障技術，一方面系統性的處理了該問題，另一方面該技術極大的簡化了問題處理，其他語言可以很容易參考實現，大大降低了分佈式事務的使用門檻

Seata 目前版本 (截止 2021-12-25 的版本爲 1.4.2) 還是需要業務手動處理

TCC 事務

dtm 和 Seata 都支持了 TCC 事務。因爲現在的微服務框架，或者服務網格通常會進行失敗重試，因此 dtm 在這方面做了很好的設計，允許重試，不會產生任何問題。

Seata 的 TCC 對重試不友好，需要關閉重試，避免出現問題。

XA 事務

dtm 和 Seata 都支持 XA 事務，他們的接口差別較大。dtm 採用的是回調函數形式的接口，而 Seata 採用的是 Java 特有的註解形式接口

AT 事務

AT 事務是 Seata 獨有的事務模式，我的觀點是，該模式是 XA 的手動實現，在適用場景、性能、使用注意點，與 XA 都非常相近，但使用上需要特別注意，否則容易觸發有髒回滾的問題，因此建議讀者如果遇見使用 AT 的場景，都可以考慮使用 XA 事務

SAGA 事務

Seata 的 Saga 實現採用了狀態機，優點是可以做到靈活配置，缺點是上手難度非常高。一個簡單的分佈式事務，使用 Saga 的狀態機 Json 配置，可以達到將近 90 行，而這部分配置可讀性很差，可調試性也很差。

dtm 在 SAGA 事務設計選擇上，做了部分用戶調研，發現使用狀態機的用戶非常少，許多經驗豐富的程序員研究 Seata 的 Saga 狀態機使用，也是困難重重。在收集了部分用戶在長事務上面的需求之後，dtm 選擇了新的實現方式：支持併發的 Saga。這項選擇的重要結果是，dtm 的用戶中，很多人選擇使用簡單 Saga。而部分高級需求可以通過一些簡單的技巧解決，詳情參考 SAGA

二階段消息

dtm 支持了二階段消息事務模式，該模式受到 RocketMQ 的事務消息啓發。這裏我們起了一個新名字的主要原因是，“事務消息”和 “事務模式” 很容易就把大家弄混了。

二階段消息提供了比本地消息表和事務消息更簡單的架構，更易用的接口：PrepareAndSubmit，該接口將本地消息表和事務消息的所有架構細節全部隱藏，新手只需要按照接口調用，填寫相關的業務邏輯和下一階段服務調用即可，其他內容不用關心。進一步降低了消息最終一致性問題的解決難度。

二階段消息也可以退化爲一階段消息，就跟普通的可靠消息類似，但是提供了更豐富的功能，例如支持同步選項。

二階消息是 DTM 提出的新架構適用於無需回滾的數據一致性場景，非常適合替換原有本地消息表和事務消息方案

Seata 暫時未支持這種事務模式，未來可能會對接 RocketMQ

單服務多數據

dtm 的 TCC 和 SAGA 事務支持單服務多數據源，詳細的使用方式會在近期補充進文檔

Seata 暫未支持這種場景

通信協議

dtm 支持 HTTP、gRPC，同時也支持基於 gRPC 的微服務協議，目前已支持 go-zero、Polaris。未來可以非常便捷的接入更多新的協議，如有需求，也可以接入 Spring cloud

Seata 則對 Java 領域的微服務協議支持較多，例如 Spring cloud、Dubbo 等

DTM 的更多優點

極快的上手速度

DTM 支持 brew 一鍵安裝，支持無配置啓動，運行第一個事務，只需要幾行命令即可，比分佈式事務領域的其他框架，便捷很多，大幅降低新手上手速度

完整的性能測試報告

DTM 在性能上也非常好，對於使用的 Mysql/Redis 存儲引擎，可以充分利用他們的性能，達到理論上的性能上限。DTM 給出了性能測試的完整過程，也有部分用戶進行了實際的壓測，獲得了近似的結果。

SEATA 暫未看到官方的性能測試報告

文檔齊全

DTM 的定位是一站式分佈式事務解決方案，能夠大量應用於現代微服務場景，例如希望將 DTM 用於每個採用了微服務架構的訂單系統，解決其中數據不一致的問題，而不僅僅是對一致性要求高的個別應用。

因此 DTM 的文檔，對分佈式事務的理論進行了詳細講解，糾正了許多大家對分佈式事中的錯誤理解，並提出了新的架構。另外 DTM 引入的多項創新，多項降低系統複雜度的核心技術，都會通過文檔，詳細介紹給大家，方便大家從舊方案，遷移到新方案。

bug 率低

DTM 沒有專門的測試人員，穩定性主要是通過自動化測試來保證的。DTM 的測試覆蓋率達到 95+%，把重要的路徑全部覆蓋，因此在多個重度用戶接入、到測試、到壓測、到線上運行的過程中，通常是零 bug，遇見的問題，多爲需要新特性，多爲環境兼容等問題。

迭代速度快

因爲 DTM 的穩定性是有自動化測試來保證的，因此添加新特性，重構等，只需要按照新特性添加相關的測試用例，而不需要擔心引入新的 bug，不用人工測試，因此可以獲得極快的迭代速度

可以從 roadmap 中看到，雖然 DTM 開源不久，但是已經添加了大量的特性

項目地址

關於分佈式事務更多的理論知識與實踐，可以訪問以下項目和公衆號：

https://github.com/dtm-labs/dtm

關注【分佈式事務】公衆號，獲取更多分佈式事務相關知識，同時可以加入我們的社羣

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QCLjyVyyZDfHOY_ZY23tSA

猜你喜歡