手把手教你实现一个Seata(firstDay)

Seata 阿里巴巴开源的分布式事务处理框架

官方地址就不贴了 直接Google即可。

分布式事务产生的背景

现在都是分布式服务了 就会有不同的服务不同的数据源。就会产生分布式的问题。比如下了订单 我要调用支付接口 调用商品接口 调用其他下游接口。如果支付服务因为网络问题没有调用成功 那么其他服务也应该全部失败回滚掉。这个时候如果其他服务成功了 就会造成数据不一致的问题。可以想想你如果商品库存扣掉了 货发了。但是没收到钱是什么感觉。等着N+1吧 嘿嘿

分布式事务解决方案

• XA 很多DB都支持的方案 具体的不展开

• 2pc

• 分成两个阶段 准备阶段和提交阶段 有AP TM RM 三个角色。简单点说就是参与者收到消息进行prepare操作 然后把结果返回给TM

• 提交阶段。TM根据返回的结果进行判断。如果都成功commit 失败rollback

• 问题:

        同步阻塞,通信都是同步的 会导致整个事务的长时间延迟
        很容易看出来TM的单点问题
        如果网络问题 导致TM发给AP存在丢失 就会造成数据不一致

• 3pc

• 三阶段提交 多了一个CanCommit和PreCommit阶段 并且使用TimeOut来控制阻塞问题

• 还是没有解决核心的问题。比如单点问题 只是相比较2pc多了点优化罢了。类似UDP和TCP的区别

• TCC

• TCC全名叫try-confirm-cancel 核心思路就是 针对每一个操作都注册一个与其对应的确认和补偿。因为不依赖DB所以可以通过代码来保证。其实就是一个应用层面的2pc

• TCC 三个阶段

• try:对AP进行check和prepare

• confiem:对try阶段预留的资源进行确认

• cancel:对try预留的资源cancel

看起来和2pc/3pc很像 但是TCC强调的是事后补偿和对于AP的提前预留 TCC没有说明如何做。
如何做是要业务层面解决。
    比如在转账的场景:预留可以把账号里面的资金进行冻结,这样这个资金就只能在当前事务流转
对于异常的场景 TCC也没说怎么做。毕竟三者都会业务定义。
    如果Try成功 confirmException就一直重试
    有日志 应用日志重试。这样开发代价较大
    依赖DB 异常后使用DBRollback
当然实现TCC要注意几个点：
  - 空回滚。try没有执行 出发cancel 要允许cancel成功
  - 防悬挂控制 cancel因为网络原因先执行了 try就直接fail掉
   - 老生常谈的 幂等
TCC的问题
    confirm和cancel阶段失败后要完全靠业务自己处理
    都需要实现TCC三个接口
    老旧业务不好改

• SAGA

• 一种长时间运行的trx。核心思想就是拆分大事务为短事务。由工作流负责协调。流程正常完成就代表成功，失败就补偿回滚

TCC vs Saga

两者都属于补偿。saga没有Try会产生实际的trx痕迹.TCC利用了数据的中间态,cancel是把中间态撤销 不存在污染的问题

使用场景对比

• TCC适合那种执行时间确定并且短 对一致性要求较高，数据隔离性强的业务

• Saga适用于业务流程多的 比如转账这种

• TCC对老业务不友好

Seata

阿里开发的 致力于提供高性能和简单易用的分布式事务服务。

seats提供

• AT

• TCC

• SAGA

• XA

最特殊的是AT 通过拦截 解释SQL对数据addLock 回滚进行基于2pc的一个实现。

特点是无入侵。用户只需要关心自己的业务SQL。用户的业务SQL作为一阶段，seata框架自动生成事务的二阶段提交和回滚操作

一阶段 拦截SQL 解析语句 找到数据 保存成beforeimage 执行业务语句 更新之后保存为afterimage
二阶段 如果提交的话 直接删掉快照数据。失败就取出undo表数据 补偿写入

paxos

实现较难 目前好像只有MySQL的CLUSTER是用这个的。

如何实现一个分布式事务框架

• HOW ?

• 开始全局事务 -〉 branch trx1 commit ;branch trx2 commit -> catch exception -> rollback

从上面就能看出来 只要保证分支事务的一致性就能实现

太多了 firstDay先介绍概念 后面就贴代码