分布式专题（十八）分布式事务

雨点打透心脏的1/2处 2023-05-21 07:04 179阅读 0赞

> 根据微服务架构的鼻祖 Martin Fowler 的忠告，微服务架构中应当尽量避免分布式事务。  
> 分布式事务的讨论主要聚焦于强一致性和最终一致性的解决方案。

# 一致性理论 #

分布式事务的目的是保障分库数据一致性，而跨库事务会遇到各种不可控制的问题，如个别节点永久性宕机，像单机事务一样的 ACID 是无法奢望的。

另外，业界著名的 CAP 理论也告诉我们，对分布式系统，需要将数据一致性和系统可用性、分区容忍性放在天平上一起考虑。

两阶段提交协议(简称2PC)是实现分布式事务较为经典的方案，但 2PC 的可扩展性很差，在分布式架构下应用代价较大，eBay 架构师 Dan Pritchett 提出了 BASE 理论，用于解决大规模分布式系统下的数据一致性问题。

BASE 理论告诉我们：可以通过放弃系统在每个时刻的强一致性来换取系统的可扩展性。

# CAP 理论 #

在分布式系统中，一致性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance)3 个要素最多只能同时满足两个，不可兼得。其中，分区容忍性又是不可或缺的。

![format_png][]

*  一致性：分布式环境下，多个节点的数据是否强一致。
 *  可用性：分布式服务能一直保证可用状态。当用户发出一个请求后，服务能在有限时间内返回结果。
 *  分区容忍性：特指对网络分区的容忍性。

举例：Cassandra、Dynamo 等，默认优先选择 AP，弱化 C;HBase、MongoDB 等，默认优先选择 CP，弱化 A。

# BASE 理论 #

核心思想：

*  基本可用(**B**asically **A**vailable)：指分布式系统在出现故障时，允许损失部分的可用性来保证核心可用；
 *  软状态(**S**oft state)：指允许分布式系统存在中间状态，该中间状态不会影响到系统的整体可用性；
 *  最终一致性(**E**ventual consistency)：指分布式系统中的所有副本数据经过一定时间后，最终能够达到一致的状态；
 *  原子性（A）与持久性（D）必须根本保障；
 *  为了可用性、性能与降级服务的需要，只有降低一致性( C ) 与 隔离性( I ) 的要求；
 *  酸碱平衡(ACID-BASE Balance)；

BASE 是对 CAP 中 AP 的一个扩展

# 一致性模型 #

数据的一致性模型可以分成以下三类：

*  强一致性：数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现。
 *  弱一致性：数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到。
 *  最终一致性：弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。

# 分布式事务TCC模型分析 #

![format_png 1][]  
如果服务A和服务B之间是同步调用，比如服务C需要按流程调服务A和服务B，服务A和服务B要么一起成功，要么一起失败。  
针对这种情况，目前业内普遍推荐使用TCC事务来解决的！

## 正文 ##

ok,老规矩，我们先套一个业务场景进去，如下图所示  
![format_png 2][]  
那页面点了支付按钮，调用支付服务，那我们后台要实现下面三个步骤  
\[1\] 订单服务-修改订单状态  
\[2\] 账户服务-扣减金钱  
\[3\] 库存服务-扣减库存  
达到事务的效果，要么一起成功，要么一起失败！就要采取TCC分布式事务方案！

### **概念** ###

TCC的全称是（Try-Confirm-Cancel）。如下图所示  
![format_png 3][]  
*ps:TCC又可以被称为两阶段补偿事务，第一阶段try只是预留资源，第二阶段要明确的告诉服务提供者，这个资源你到底要不要，对应第二阶段的confirm/cancel，用来清除第一阶段的影响，所以叫补偿型事务。*

再打个比方，说TCC太高大上是吧，讲RM中的prepare、commit、rollback接口，总知道吧。可以类比的这么理解  
![format_png 4][]  
那差别在哪呢?  
rollback、commit、prepare，站在开发者层面是感知不到的，数据库帮你做了资源的操作!  
而try、confirm、cancel，站在开发者层面是能感知到的，这三个方法的业务逻辑，即对资源的操作，开发者是要自己去实现的！  
好，下面套入我们的场景，怎么做呢。比如，你的订单服务中本来只有一个接口

//修改代码状态
    orderClient.updateStatus()；

都要拆为三个接口，即

orderClient.tryUpateStatus()；
    orderClient.confirmUpateStatus()；
    orderClient.cancelUpateStatus()；

**注意了**：面试官如果问你，TCC有什么缺点？这就是很严重的缺点，**对代码入侵性大！**每套业务逻辑、都要按try(请求资源)、confirm(操作资源)、cancel(取消资源)，拆分为三个接口！

具体每个阶段，每个服务业务逻辑是什么样的呢?  
假设，库存数量本来是50，那么可销售库存也是50。账户余额为50,可用余额也为50。用户下单，买了1个单价为1元的商品。流程如下:  
**Try阶段**  
订单服务:修改订单的状态为**支付中**  
账户服务:账户余额不变，可用余额减1，然后将1这个数字冻结在一个单独的字段里  
库存服务:库存数量不变，可销售库存减1，然后将1这个数字冻结在一个单独的字段里  
**confirm阶段**  
订单服务:修改订单的状态为**支付完成**  
账户服务:账户余额变为(当前值减冻结字段的值)，可用余额不变(Try阶段减过了),冻结字段清0。  
库存服务:库存变为(当前值减冻结字段的值)，可销售库存不变(Try阶段减过了)，冻结字段清0。  
**cancel阶段**  
订单服务:修改订单的状态为**未支付**  
账户服务:账户余额不变，可用余额变为(当前值加冻结字段的值)，冻结字段清0。  
库存服务:库存不变，可销售库存变为(当前值加冻结字段的值)，冻结字段清0。

### **伪代码** ###

接下来从代码程序来说明，为了便于演示，将入参略去。  
本来，你支付服务的代码是长下面这样的  
![format_png 5][]  
那么，用上TCC模型后，代码变成下面这样  
![format_png 6][]  
注意了，这种写法其实严格上来说，不是不行。看你业务场景，因为存在一些瑕疵，看你自己有没办法接受  
**(1)cancel或者confirm出现异常了，你怎么处理？**  
例如在cancel阶段执行如下三行代码

orderClient.cancelUpdateStatus();
    accountClient.cancelDecrease();
    repositoryClient.cancelDecrease();

你第二行出现异常了，第三行没跑就退出了，怎么办？你要对此进行业务补偿！  
**(2)大量逻辑重复**  
你看啊，我们的执行架构其实是这样的

try{
        xxclient.try();
    }catch(Throwable t){
        xxclient.cancel();
        throw t;
    }
    xxclient.confirm();

有没办法让这个架子交给框架去执行，我们告诉框架，你在每个阶段要执行哪些方法就好！

因此，需要引入TCC分布式事务框架，事务的Try、Confirm、Cancel三个状态交给框架来感知！你只要告诉框架，Try要执行啥，Confirm要执行啥，Cancel要执行啥!如果Cancel过程出现异常了，框架有内部的补偿措施给你恢复数据！  
以分布式tcc框架**hmily**为例，如果出现cancel异常或者confirm异常的情况，在try阶段会保存好日志，Hmily有内置的调度线程池来进行恢复，不用担心。  
那hmily，怎么感知状态的呢？也很简单，就是切面编程，核心逻辑如下几行  
![image][]  
我们在使用过程中，只要通过@Tcc注解告诉框架confirm方法执行啥，cancel方法执行啥即可！其他的交给框架帮你处理！  
好了，不多说了，再说下去就是hmily源码解析了，大家有空自己去了解！

参考：[https://www.jianshu.com/p/ee4071d0c951][https_www.jianshu.com_p_ee4071d0c951]  
           [https://www.cnblogs.com/rjzheng/p/10164667.html][https_www.cnblogs.com_rjzheng_p_10164667.html]

[format_png]: /images/20230521/df56a7ea905744518fc7ca3a3c786617.png
[format_png 1]: /images/20230521/b0dd2a5f0de347a4bfd02ef1273aafdd.png
[format_png 2]: /images/20230521/2f78d54ee2044b3581e466643acc0846.png
[format_png 3]: /images/20230521/b22206e66b2644d5b02158f8c111eb84.png
[format_png 4]: /images/20230521/e1e144d647d540bb8ab8a9198d9b3b94.png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNzI1NDI5LzIwMTgxMi83MjU0MjktMjAxODEyMjMxNjIyMTQ2MTYtMTM2NTg1NjkwNi5qcGc?x-oss-process=image/format,png
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNzI1NDI5LzIwMTgxMi83MjU0MjktMjAxODEyMjMxNjIyMjIwODctMTQyMTE1NzQxLmpwZw?x-oss-process=image/format,png
[image]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly93d3cuY25ibG9ncy5jb20vaW1hZ2VzL2NuYmxvZ3NfY29tL3JqemhlbmcvMTM1ODI1Ni9vXyVlNSViMSU4ZiVlNSViOSU5NSVlNSViZiVhYiVlNyU4NSVhNyUyMDIwMTgtMTItMTMlMjAlZTQlYjglOGIlZTUlOGQlODg1LjQ5LjE5LnBuZw?x-oss-process=image/format,png
[https_www.jianshu.com_p_ee4071d0c951]: https://www.jianshu.com/p/ee4071d0c951
[https_www.cnblogs.com_rjzheng_p_10164667.html]: https://www.cnblogs.com/rjzheng/p/10164667.html