分布式事务浅析

作者: caibmck | 来源:发表于2020-02-10 22:26 被阅读0次

老生常谈，分布式架构，分布式事务，那分布式事务是个怎么回事呢，那我们先了解什么是分布式架构。
简单来说把功能模块化和领域化，然后各个邻域协调工作完成一个功能。还不太懂就看下下面这个图吧

图一.png

是不是看了这个图，也是还是看不懂，看不懂就看不懂吧，那我解释下吧，
需求 : 我需要一个六角星，去开启光明能量
实现：长方形 + 圆 + 六边形 = 六角星
那么很多人都这么想。那我就加就好了呀那们A 系统就出来了。可是需求量增加，一个A 系统抗不住，或者说，当客户需要七角星怎么办，一个系统，只能在里面改造，耦合性太高，要求也很高，因为必须了解整个A 系统怎么创造出来的六角星，才能改造下，生产出七角星，而且还不能影响六角星的生产，反正各种弊端。

那么就有人想，那能不能把长方形，圆形，六边形解放出来，而且还可以随时加入不同的其他模块，而尽量不影响其他的模块。那么B 系统就是应运而生了。那么呢，B 系统应该怎么理解呢。那我这里先简单介绍下把。
B 系统发一个请求进来，长条的长方型（网关）解析之后，告诉系统我需要六角星，那么需要用到，长方形，圆形，六边形。因为他们之间是独立的，那么就会出现单点故障的问题，那们六边形就会创建不出来或者创造出一个乱七八糟的东西。这些都不知我们要的，那我们应该怎么办呢，好吧。说了这么就今天我的主角正式上场，分布式事务。

分布式事务

关于事务必要要了解

ACID

原子性（Atomicity）
原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
一致性（Consistency）
事务前后数据的完整性必须保持一致。
隔离性（Isolation）
事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
持久性（Durability）
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响

关于分布式事务，就不能不说 CAP 理论和BASE 理论

CAP :
C : Consistency（一致性）
A : Availability（可用性）
P: Partition tolerance（分区容错性）

一般来说，满足CAP 的架构是不存在的，但是业务使然，肯定不能出错，所以很多架构和框架都是在一致性和可用性做取舍。

BASE
base 是在CAP 的基础上提出了的一个理论，BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。

分布式事务，现在主流的 2pc 二阶段式提交。tcc (try -comfirm -cancel) ,还有就是MQ 补偿，为了事务的最终一致性。

2pc 二阶段式提交
其实二阶段提交时什么呢，就是加入了一个协调者（tx）可以联想下上面那个图，下面那个长条的长方形，把它理解为tx,那么他时怎么管理的呢，首先，tx 要知道这三个模块是属于同一个事务的，那就要有唯一的ID 标识，我们称 tx_id。

tu2.png

那么其实二段式提交就是，把提交事务的工作交给了tx, 他来判断整个事务到底成功了没有，如果成功，那么他通知各个模块提交事务，如果没有成功，那么通知各个模块回滚事务，从而达到一致性。

TCC (try -confirm -cancel)

TCC 很好理解，故名思意，也很好用，但是这个侵入业务中，写起来简单，但是麻烦。怎么说呢，下面写份伪代码，大概的思路就是这样的。

def do ={ do something ...}

def confirm = { confirm }

def cancel = { cancel }

def main ={
try 
  do
catch  cancel
confirm
}

do 方法是具体的业务，cancel 和 confirm 这里是要一个main 里面，但是正常业务很多都是回调或者补偿进来的。这只是个思路啦，每个TCC 框架都会有自己的一套具体的实现的。

MQ 补偿的，暂时这次先不讲。

说了这么多理论，那我们是不是开始上硬菜了，好吧，直接上代码。

dapeng 的全局事务

dapeng 的全局事务的设计就是为了解决分布式事务的问题。
首先，先了解两个概念

名词	描述
全局事务	一个支持分布式事务服务接口方法的开始到结束称为一个全局事务
事务过程	一个全局事务中调用其它支持分布式事务接口方法，该方法的开始到结束称为一个事务过程

架构设计：

05A5B7ED-F809-4d84-BF0B-F4E1E9A31B7B.png

C66C0EEE-D399-45f3-B956-192A10AE06B0.png

接口设计

service DemoService{
    /**
    * @SoaGlobalTransactional
**/
    void Do()

    i32 doAddStock(i32 id,i32 num)

    i32 doSubStock(i32 id,i32 num)

}

service ProcessDemoService{
/**
    *  @IsSoaTransactionProcess
**/
    i32 doAddStockForProcess(i32 id,i32 num)

    i32 doAddStockForProcess_rollback(i32 id,i32 num)
    /**
    * @IsSoaTransactionProcess
**/
    i32 doSubStockForProcess(i32 id,i32 num)

    i32 doSubStockForProcess_rollback(i32 id,i32 num)

}

dapeng 使用thrift 协议生成接口，只要在接口方法处声明，@SoaGlobalTransactional 这个是全局事务开启的方法，@IsSoaTransactionProcess 声明这个是过程方法，过程方法需求定义自己的回滚方法，规则是方法名_rollback。 rollback 方法和过程方法入参一致（有些版本不需要参数）

实现

override def Do(): Unit = {
    // 1 do 2 do addStock  3 do doSubStock
    LOG.info(" ---------------- do start -----------------")
    // 都在同一个事务里 ， 主流程出错
    val id = 1
    LOG.info(s"---------------------- (1)  id ->${id} ")

    LOG.info(s" id -> ${BaseHelper.getTransactionId} , seq -> ${BaseHelper.getTransactionSequence} ")


    new ProcessDemoServiceClient().doAddStockForProcess(id,10)

    new ProcessDemoServiceClient().doSubStockForProcess(id,5)

    err

    LOG.info( "-------------- do end ---------------")
  }
  private def err: Unit ={
    assert(false," err ")
  }

  override def doAddStock(id:Int,num: Int): Int = {
   DemoSql.doAddStock(id,num)
    1
  }

  override def doSubStock(id:Int,num: Int): Int = {
    DemoSql.doSubStock(id,num)
    2
  }

过程事务方法

 override def doAddStockForProcess(id: Int, num: Int): Int = {
    LOG.info(s" id-> ${BaseHelper.getTransactionId()} , seq -> ${BaseHelper.getTransactionSequence()} ")
    DemoSql.doAddStock(id,num)
  }

  override def doAddStockForProcess_rollback(id: Int, num: Int): Int = {
    LOG.info(s" id-> ${BaseHelper.getTransactionId()} , seq -> ${BaseHelper.getTransactionSequence()} ")
    DemoSql.doSubStock(id,num)
  }

  override def doSubStockForProcess(id: Int, num: Int): Int = {
    LOG.info(s" id-> ${BaseHelper.getTransactionId()} , seq -> ${BaseHelper.getTransactionSequence()} ")

    DemoSql.doSubStock(id,num)
  }

  override def doSubStockForProcess_rollback(id: Int, num: Int): Int = {
    LOG.info(s" id-> ${BaseHelper.getTransactionId()} , seq -> ${BaseHelper.getTransactionSequence()} ")
     DemoSql.doAddStock(id,num)
  }

执行do 主事务方法，调用两个过程方法，最后err ，主事务回滚，过程事务执行rollback 方法，达到最终一致性。
日志贴图

AF8B533D-E06A-47f3-8361-DD7611DA1AD5.png

175BEBE0-422E-47cd-82EB-0E917ED2DF14.png

从这里可以看出，dapeng 的分布式事务设计，主要是tcc 的设计思路。

然后我们看下最近热门的 seata 框架，阿里开源出来的解决分布式事务的一个框架。

首先我们先看下seata 的git 的地址
https://github.com/seata/seata

从简介中可看出来，seata 是有一个 tc ,从上文的对分布式事务处理方案中可以得出，这seate 应该是一个 2pc 二阶段式提交提交框架，那事实上是这样的吗?

我们继续往下看，seate 的文档
https://github.com/seata/seata/wiki

68747470733a2f2f63646e2e6e6c61726b2e636f6d2f6c61726b2f302f323031382f706e672f31383836322f313534353230393135353538392d31316562653032642d373265662d343761342d393266352d3336626535346665396231372e706e67.png

从图中可看到， Business 是TM ,向TC注册Global Transation ,确定applicationId,整个调用链就能通过这个ID关联起来，调用Storage,向TC 注册，seate 的一个创新的地点，也就是"解决" 二阶段提交的一个方法是，先子系统commit事务，会加个锁锁住这条记录防止更新，记录undolog,并向TC注册。下个服务的调用链Order,Account 也一样，commit,加锁，记录undolog，从图中看出，每个子系统都是RM,当TM,也就是Business 完成之后，就会通知TC,Global commit ,那么TC 会通知每个RM,每个RM 就会执行commit ,释放锁。如果调用链中出现异常，这个异常就会返回到TM,TM 会向TC 发出rollback 请求。TC 会给各个TM 发出回滚的通知，每个TM 会解析undolog,回滚数据，释放锁。

在这个过程中，主要是 TC ,TM , RM 这个三个角色在各司其职，然后完成整个分布式事务工作。从这个过程中，感觉seate 像不像二阶段式提交，和TCC 的混合体（反正我是这样觉得的）。
TC 作为一个协调者，掌控全局，但是却没有强制挂起子系统的事务，而是让其提交事务，释放资源，这个解决了二阶段式提交的效率问题。而创新的创建了一个undolog 的表，记录undolog, 释放了TCC 中cancel 的工作量和解决入侵业务的问题。
总结：seate 是一个很优秀的分布式事务中间件。
至于seata 是怎么做的，源码分析什么的，可以看下seate 的文档，很多人分析的很不错，我在这里就不说了。
当然，我们从GitHub 上查下分布式事务的解决方案，也会有很多解决方案,像Raincat, hmily ，lcn 等都是非常优秀的框架。这些下次分解咯

分布式事务浅析

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读