最強分佈式事務框架怎麼煉成的？

一、什麼是事件驅動架構

事件驅動架構是一種促進生產的軟件架構範式。事件驅動架構在用微服務構建的現代應用中非常普遍，它用事件來觸發、解耦服務之間的通信。事件可以是狀態的變更，比如將商品放入購物車；也可以是某種標識，比如訂單的發貨通知。

在傳統的軟件架構中，應用邏輯是通過請求、過程驅動的。一個請求執行一段邏輯同步返回一個響應，在業務邏輯中，將要執行的代碼按照過程順序進行編排。而事件驅動架構中，事件消費者會以異步的方式處理事件生產者產生的事件，原來過程當中的邏輯交給事件消費者去處理，解開服務之間的耦合，使應用的邏輯聚焦，應用的職責單一，代碼更加簡潔，也能提升系統的響應能力。

二、分佈式事務的事件驅動架構

在 2020 年，本文作者開源了 Go 語言的分佈式事務框架 Seata-Golang。Seata-Golang 實現 AT 模式和 TCC 模式，這兩種模式都是過程驅動。到了 2022 年，隨着對雲原生技術的理解深入，從 Kubernetes Control-Loop 思想中獲得靈感，全新設計了高性能、無侵入、事件驅動的 Go 語言分佈式事務框架 hptx，以及支持跨語言分佈式事務、讀寫分離、分庫分表的 Mesh 方案 DBPack。這兩款產品都能解決分佈式事務問題，前者只支持 Go 語言，後者支持任意編程語言。他們採用了相同的事件驅動架構。下面進行詳細的說明。

過程驅動

在 Seata 的設計中，事務發起者發起全局提交後，首先會判斷該事務是否允許異步提交，如果允許，則直接返回提交成功，然後由 AsyncCommittingSessionManager 來異步地通知每個分支事務提交，AT 事務默認允許異步提交。如果不允許異步提交，事務協調者會依次通知全局事務參與者即每個分支事務提交，所有分支事務提交成功後，同步返回給事務發起者全局事務提交的結果，如上圖。事務協調者通知事務參與者提交過程中發生了異常，會將該全局事務標記爲 CommitRetrying 狀態，將會有一個 RetryCommittingSessionManager 定時從持久存儲中撈取標記的全局事務重試提交。

全局回滾的過程與上圖類似，全局回滾時，AT 模式和 TCC 模式都是同步執行，依次通知每個分支事務回滾，然後再響應回滾結果給事務發起者。如果回滾失敗，則將全局事務標記爲 RollbackRetrying，由 RetryRollbackingSessionManager 定時撈取標記的全局事務數據重試回滾。

Seata-Golang 的用戶經常會問一個問題，事務協調者 TC Server 怎麼做高可用？Seata 包括 Seata-Golang 默認推薦使用 Mysql 數據庫作爲 TC 狀態數據的持久化存儲。TC Server 本身則是無狀態應用，可以部署多個副本，但這裏就存在一個問題：多個對等副本里的 AsyncCommittingSessionManager、RetryCommittingSessionManager、RetryRollbackingSessionManager 都會從數據庫去撈取對應的數據執行，會導致事務的提交、回滾重複執行，雖然 AT 模式天然做到冪等，TCC 模式由用戶保證冪等，但總是存在一定的資源浪費，且不夠優雅。

事件驅動

上圖展示了 hptx 和 dbpack 的事務協調邏輯，事務發起者 AggregationSvc 發起全局事務提交、回滾，僅僅是修改 ETCD 中的數據狀態，然後立即返回。訂單服務和商品服務使用前綴 bs/${appid} Watch 存儲在 ETCD 中的分支事務數據，當分支事務的數據發生過變更後，ETCD 馬上推送一個變更事件給相應服務，訂單服務和商品服務收到變更事件後，將數據加入 workqueue 去執行提交或回滾的邏輯。AggregationSvc 提交、回滾時不會調用 OrderSvc、ProductSvc 的接口，整個過程通過 ETCD 解耦後異步執行。

事務分支提交或者回滾失敗後，會重新進入到 workqueue 當中繼續消費，直至提交、回滾成功，或回滾超時（AT 模式回滾操作涉及到全局鎖的釋放，需要設置超時時間，即 retry_dead_threshold）。

在這個架構中，已經沒有中心化事務協調者 TC Server，用戶只需要關心自身應用的高可用，如果應用多副本部署，hptx 和 dbpack 會通過 etcd 選主，只有選爲 master 的副本才能 watch 自身產生的分支事務數據去做提交、回滾，避免了提交、回滾邏輯重複執行的問題。集成 hptx，只需要依賴相應的 sdk，而不需要部署額外的 TC Server，但狀態數據的存儲由原來的 Mysql 換成了 ETCD。

三、新架構帶來的好處

全新的、雲原生的、事件驅動架構，更加簡潔，性能更強。採用 hptx 的應用事務協調性能比 Seata-Golang 提升 1 倍，通過 dbpack 以 mesh 方式協調分佈式事務性能比 seata-golang 提升了百分之 50。下面是一些測試數據：

	環境	性能
seata-golang	2018 款 Mac book pro	每秒 18.54 筆事務
hptx	2018 款 Mac book pro	每秒 38.89 筆事務
dbpack	2018 款 Mac book pro	每秒 28.09 筆事務
hptx	阿里雲 ecs ecs.sn1ne.xlarge (4 核 8G)	每秒 35.15 筆事務

hptx 是當前性能最強的雲原生、無侵入分佈式事務解決方案，選擇其他內存型存儲組件理論上可以得到更高的性能，但綜合可靠性和性能，ETCD 是目前最好的選擇。

四、結語

經過持續地在分佈式事務領域的研究總結，使分佈式事務框架不斷進化，從最初的兼容 java seata 的 seata-golang v1 版本，到雲原生的、無侵入的、基於 grpc 的 seata-golang v2 版本，到基於 ETCD watch 機制的、事件驅動的 hptx，再到跨語言的 dbpack，分佈式事務一直在進化，能力也在進一步增強。

歡迎感興趣的同學加入我們社區一起交流討論分佈式事務問題、DBMesh 問題，進羣或參與社區建設請添加微信：scottlewis。