Go 夜读第 155 期：从零到一实现 TCC 分布式事务框架

Go 夜读
1

【预告】基于 gotcc——纯 golang 实现的 tcc sdk 框架分享从零到一实现 TCC 分布式事务框架

本着【理论先行实践紧随】的原则，和大家共同探讨 tcc 分布式事务实现方案，并逐帧拆解如何从零到一搭建 tcc 分布式事务框架。

大纲

  • tcc 分布式事务理论
  • gotcc 架构设计
  • 各模块核心源码串讲
  • 使用案例介绍

分享者自我介绍

小徐先生
滴滴出行，营销业务，Go 后端研发
bilibili——小徐先生1212
知乎——小徐先生
微信公众号——小徐先生的编程世界

计划分享时间

2024-06-16 20:00:00 UTC+8（周日晚上）

分享地址

Bilibili 直播：

https://live.bilibili.com/h5/11171965

视频号直播：
Go 夜读

Slides

gotcc技术分享.pdf (5.1 MB)

参考资料

gotcc分布式事务开源sdk
分布式事务理论篇
分布式事务实战篇

3 个赞
2

哇 小徐 关注了很久的大佬 公众号的文章写得特别好 由浅入深 逻辑清晰

3
  1. 因为其中还讲到需要考虑cancel比try先到的情况, 请问Component的Try和Confirm/Cancel的实现难度似乎有点大, 一般怎么实现呢?
  2. TXManager中Component.Try没做重试, PPT却说Component.Try需要支持at least once, 这个要求是否就多此一举了.
4

1 component 需要维护一个 txid 维度的处理状态. 如果 cancel 先到达，也记录 canceled 状态，并回绝后续的 try 请求. 即所谓的空回滚处理机制. 实现难度大这个点，正如我在开篇介绍的时候说的，tcc 的劣势就是在于较大的成本转嫁给到了 component 实现方，这个选择方案时权衡就好了. 具体的实现我在项目中给了案例，参见 https://github.com/xiaoxuxiansheng/gotcc/example

5

2 你说的是有道理的. 从 gotcc 实现的 txmanager 主干流程来讲，是不针对第一阶段的 try 重试的. 但是通常 component try 方法会涉及到 rpc 或者 http 之类的 io 交互，这部分自由度本身留给了实现方，如果 io 框架层面启用了重试机制的话，那么从底线思维出发，下游理论上也要支持幂等. 此外这第2点可以结合我第1点的回答来看，本身为了支持空回滚机制，下游已经维护了一个 txid 的状态值了，那么复用这个状态也能实现幂等，本身成本不会高太多