那些用 Go 实现的分布式事务框架

作者： 吴亲库里 2021-12-09 10:45:19

开发

后端

分布式 eata是由阿里开源的分布式事务服务，目前为用户提供了AT、TCC、SAGA、XA的事务模式，整体采用的是两阶段提交协议。Go版的seata-golang 目前好像只实现了mysql的AT、TCC模式，作者现在不咋更新了。

公司主营业务：成都网站设计、成都网站制作、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联建站是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联建站推出襄阳免费做网站回馈大家。

[[439474]]

本文转载自微信公众号「RememberGo」，作者吴亲库里 。转载本文请联系RememberGo公众号。

开篇

不知不觉竟然一个月没更新了，人一旦懒下来只会越来越懒。

最近对分布式事务产生了一些兴趣，查阅了一些文章以及论文。这篇文章主要介绍我看的两个项目，不涉及一些理论知识。

• 阿里开源版本的Seata，主要看了Go实现的seata-golang(落后java版)
• 以及前段时间很多公众号都发的dtm。

Seata简介

Seata是由阿里开源的分布式事务服务，目前为用户提供了AT、TCC、SAGA、XA的事务模式，整体采用的是两阶段提交协议。Go版的seata-golang 目前好像只实现了mysql的AT、TCC模式，作者现在不咋更新了。

Seata 有几个核心角色：

• TC(Transaction Coordinator) -事务协调者。(维护全局和分支事务的状态，驱动全局事务提交或回滚)
• TM(Transaction Manager)-事务管理器。(定义全局事务的范围：开始全局事务、提交或回滚全局事务。)
• RM(Resource Manager)-资源管理器。(管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚)

当然这样看，可能还不是很理解，我拿一张官网的图加以解释。

从上图中可以看出，这三个角色所负责的工作如下，

TC

• 维护全局和分支事务状态，需要进行存储。
• 当一个分布式事务处理结束，需要通知到每个RM是commit还是rollback。

TM

• 向TC请求开启一个分布式事务，得到一个全局唯一的分布式id。
• 根据每个参与分布式事务的RM一阶段的反馈，决定二阶段向TC请求此次分布式事务是commit还是rollback(绝大部分场景下，一阶段任一RM失败，本次分布式事务失败)

RM

说的白一点就是管理参与分布式事务的各个服务(比如经典下单场景中涉及到的:订单服务、库存服务、营销服务等)

ps:个人感觉，这里的RM有点类似微服务中的中间处理层(专业术语他们管这叫bff->backend for fronted)。

• 一阶段 prepare 行为(主动)：每个RM调用 自定义 的 prepare 逻辑。
• 二阶段 commit 行为(被动触发)：如果本次分布式事务第一阶段全部RM成功，TC处理完自身状态变更后，调用各个RM自定义 的 commit 逻辑。(一阶段RM全部成功)
• 二阶段 rollback 行为(被动触发)：如果本次分布式事务第一阶段任一RM失败，TC处理完自身状态变更后，调用各个RM自定义 的 rollback 逻辑。(一阶段任意RM失败)

好了。下面可以看看seata-golang 实现的一些细节了，seata-golang 底层采用gRPC进行通信。

seata-golang

我们先看RM部分结构。

至于managers，保存支持的各大事务模式实现(TCC、XA等)，每个模式只需要实现此接口即可。

再看TC部分结构(去除部分字段)。

TC对数据的存储目前支持mysql和pgsql，即只要实现SessionManager接口，然后注入到SessionHolder的manager。

介绍完这两个基本结构，还记得我们上面说过他们之间的关系吗?

二阶段TC会根据当前事务状态去通知RM是commit还是rollback。

在初始化ResourceManager 的时候，

我们看到最终会调用TC一个 grpc 接口branchCommunicate。

对应到服务端。

我们知道gRPC有四种基础的通信模式。

• 一元模式(Unary RPC)
• 服务器端流RPC(Server Sreaming RPC)
• 客户端流RPC(Client Streaming RPC)
• 双向流RPC(Bidirectional Streaming RPC)

想要流的形式也很简单，只需要在proto方法定义中将对应的请求|响应 参数前加上stream标记，那么这个接口就是流式传送了。至于是哪种流，取决于你把stream加在哪边，如果请求和响应都加，那么就是双向流了。

客户端和服务端都可以通过stream.Send 发送请求，通过stream.Recv 接收数据。

当RM调用BranchCommunicate时，

最终处理分支事务调用manager.BranchCommit，

相应的，当TC被RM调用BranchCommunicate 后，

上面要发送给RM 通知commit 或者 rollback 数据是咋么来的呢?

当TC要通知RM进行分支commit 的时候，

最后一个就是TM，没啥理解难度。

其实seat-golang还有别的可以提一提的。

比如说，它里面通过go反射实现的动态代理功能(虽然我觉得完全没必要?)，我懒得写了。

这篇文章再写就更长了，不继续写dtm了，感兴趣的留个言，我看看要不要写一篇dtm。

参考

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

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

网站题目：那些用Go实现的分布式事务框架
文章网址：http://www.shufengxianlan.com/qtweb/news49/290899.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联