[[439474]]

本文轉(zhuǎn)載自微信公眾號「RememberGo」，作者吳親庫里 。轉(zhuǎn)載本文請聯(lián)系RememberGo公眾號。

開篇

不知不覺竟然一個月沒更新了，人一旦懶下來只會越來越懶。

最近對分布式事務(wù)產(chǎn)生了一些興趣，查閱了一些文章以及論文。這篇文章主要介紹我看的兩個項(xiàng)目，不涉及一些理論知識。

• 阿里開源版本的Seata，主要看了Go實(shí)現(xiàn)的seata-golang(落后java版)
• 以及前段時間很多公眾號都發(fā)的dtm。

Seata簡介

Seata是由阿里開源的分布式事務(wù)服務(wù)，目前為用戶提供了AT、TCC、SAGA、XA的事務(wù)模式，整體采用的是兩階段提交協(xié)議。Go版的seata-golang 目前好像只實(shí)現(xiàn)了mysql的AT、TCC模式，作者現(xiàn)在不咋更新了。

Seata 有幾個核心角色：

• TC(Transaction Coordinator) -事務(wù)協(xié)調(diào)者。(維護(hù)全局和分支事務(wù)的狀態(tài)，驅(qū)動全局事務(wù)提交或回滾)
• TM(Transaction Manager)-事務(wù)管理器。(定義全局事務(wù)的范圍：開始全局事務(wù)、提交或回滾全局事務(wù)。)
• RM(Resource Manager)-資源管理器。(管理分支事務(wù)處理的資源，與TC交談以注冊分支事務(wù)和報告分支事務(wù)的狀態(tài)，并驅(qū)動分支事務(wù)提交或回滾)

當(dāng)然這樣看，可能還不是很理解，我拿一張官網(wǎng)的圖加以解釋。

從上圖中可以看出，這三個角色所負(fù)責(zé)的工作如下，

TC

• 維護(hù)全局和分支事務(wù)狀態(tài)，需要進(jìn)行存儲。
• 當(dāng)一個分布式事務(wù)處理結(jié)束，需要通知到每個RM是commit還是rollback。

TM

• 向TC請求開啟一個分布式事務(wù)，得到一個全局唯一的分布式id。
• 根據(jù)每個參與分布式事務(wù)的RM一階段的反饋，決定二階段向TC請求此次分布式事務(wù)是commit還是rollback(絕大部分場景下，一階段任一RM失敗，本次分布式事務(wù)失敗)

RM

說的白一點(diǎn)就是管理參與分布式事務(wù)的各個服務(wù)(比如經(jīng)典下單場景中涉及到的:訂單服務(wù)、庫存服務(wù)、營銷服務(wù)等)

ps:個人感覺，這里的RM有點(diǎn)類似微服務(wù)中的中間處理層(專業(yè)術(shù)語他們管這叫bff->backend for fronted)。

• 一階段 prepare 行為(主動)：每個RM調(diào)用 自定義 的 prepare 邏輯。
• 二階段 commit 行為(被動觸發(fā))：如果本次分布式事務(wù)第一階段全部RM成功，TC處理完自身狀態(tài)變更后，調(diào)用各個RM自定義 的 commit 邏輯。(一階段RM全部成功)
• 二階段 rollback 行為(被動觸發(fā))：如果本次分布式事務(wù)第一階段任一RM失敗，TC處理完自身狀態(tài)變更后，調(diào)用各個RM自定義 的 rollback 邏輯。(一階段任意RM失敗)

好了。下面可以看看seata-golang 實(shí)現(xiàn)的一些細(xì)節(jié)了，seata-golang 底層采用gRPC進(jìn)行通信。

seata-golang

我們先看RM部分結(jié)構(gòu)。

至于managers，保存支持的各大事務(wù)模式實(shí)現(xiàn)(TCC、XA等)，每個模式只需要實(shí)現(xiàn)此接口即可。

再看TC部分結(jié)構(gòu)(去除部分字段)。

TC對數(shù)據(jù)的存儲目前支持mysql和pgsql，即只要實(shí)現(xiàn)SessionManager接口，然后注入到SessionHolder的manager。

介紹完這兩個基本結(jié)構(gòu)，還記得我們上面說過他們之間的關(guān)系嗎?

二階段TC會根據(jù)當(dāng)前事務(wù)狀態(tài)去通知RM是commit還是rollback。

在初始化ResourceManager 的時候，

我們看到最終會調(diào)用TC一個 grpc 接口branchCommunicate。

對應(yīng)到服務(wù)端。

我們知道gRPC有四種基礎(chǔ)的通信模式。

• 一元模式(Unary RPC)
• 服務(wù)器端流RPC(Server Sreaming RPC)
• 客戶端流RPC(Client Streaming RPC)
• 雙向流RPC(Bidirectional Streaming RPC)

想要流的形式也很簡單，只需要在proto方法定義中將對應(yīng)的請求|響應(yīng) 參數(shù)前加上stream標(biāo)記，那么這個接口就是流式傳送了。至于是哪種流，取決于你把stream加在哪邊，如果請求和響應(yīng)都加，那么就是雙向流了。

客戶端和服務(wù)端都可以通過stream.Send 發(fā)送請求，通過stream.Recv 接收數(shù)據(jù)。

當(dāng)RM調(diào)用BranchCommunicate時，

最終處理分支事務(wù)調(diào)用manager.BranchCommit，

相應(yīng)的，當(dāng)TC被RM調(diào)用BranchCommunicate 后，

上面要發(fā)送給RM 通知commit 或者 rollback 數(shù)據(jù)是咋么來的呢?

當(dāng)TC要通知RM進(jìn)行分支commit 的時候，

最后一個就是TM，沒啥理解難度。

其實(shí)seat-golang還有別的可以提一提的。

比如說，它里面通過go反射實(shí)現(xiàn)的動態(tài)代理功能(雖然我覺得完全沒必要?)，我懶得寫了。

這篇文章再寫就更長了，不繼續(xù)寫dtm了，感興趣的留個言，我看看要不要寫一篇dtm。

參考

https://seata.io/zh-cn/docs/overview/what-is-seata.html

https://github.com/opentrx/seata-golang