[[439474]]

本文轉(zhuǎn)載自微信公眾號(hào)「RememberGo」，作者吳親庫(kù)里 。轉(zhuǎn)載本文請(qǐng)聯(lián)系RememberGo公眾號(hào)。

開篇

不知不覺竟然一個(gè)月沒更新了，人一旦懶下來只會(huì)越來越懶。

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

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

Seata簡(jiǎn)介

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

Seata 有幾個(gè)核心角色：

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

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

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

TC

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

TM

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

RM

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

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

• 一階段 prepare 行為(主動(dòng))：每個(gè)RM調(diào)用 自定義 的 prepare 邏輯。
• 二階段 commit 行為(被動(dòng)觸發(fā))：如果本次分布式事務(wù)第一階段全部RM成功，TC處理完自身狀態(tài)變更后，調(diào)用各個(gè)RM自定義 的 commit 邏輯。(一階段RM全部成功)
• 二階段 rollback 行為(被動(dòng)觸發(fā))：如果本次分布式事務(wù)第一階段任一RM失敗，TC處理完自身狀態(tài)變更后，調(diào)用各個(gè)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等)，每個(gè)模式只需要實(shí)現(xiàn)此接口即可。

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

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

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

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

在初始化ResourceManager 的時(shí)候，

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

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

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

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

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

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

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

最終處理分支事務(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 的時(shí)候，

最后一個(gè)就是TM，沒啥理解難度。

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

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

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

參考

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

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