分布式事务浅析

港控/mmm° 2022-05-29 02:59 178阅读 0赞

之前看《数据库系统实现》中有讲一些分布式事务，稍微了解了一下，这次再好好总结一下。文中有借用了网上的一些图。有侵权联系删除。

### 数据服务性能的提升主要依靠两种方式 ###

*  数据分区（不同数据存在不同节点）
 *  数据备份（多节点拷贝，相同数据存放多个节点）  
    
    
     *  Master-Slave。读写请求都由Master负责。写请求写到Master上后，由Master同步到Slave上。问题是：单点崩溃无法提供写服务
     *  Master-Master。所有节点可以提供写服务。问题：数据一致性，以及**多节点数据冲突**

### CAP理论 ###

分布式领域有CAP理论，三者无法都同时达到最优，顾此失彼

*  一致性  
    
    
     *  强一致性
     *  弱一致性（包括最终一致性）
 *  可用性：在有节点宕机之后，仍然能够正确提供服务，好的响应性能。
 *  分区容忍性：分区之后，某些数据被分在一个单独的节点，因为各种原因导致这个节点无法访问，这是无法容忍的。解决方案就是备份节点。但是备份节点多了就会带来一致性的问题，同时写的时候要写多个节点，也会带来可用性的问题。

### Base理论 ###

即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

*  基本可用：牺牲部分的可用性，响应时间可适当变长
 *  软状态：允许数据存在中间状态，但是不会影响系统整体可用性
 *  最终一致性：经过一段时间同步，数据能够达到一致性

### 两阶段提交 ###

![Screenshot1521598291.png][]

*  1.协调者：发送消息让所有节点准备提交
 *  节点：收到消息执行事务并写好日志，回应给协调者成功或失败
 *  2.协调者：当所有节点都回复成功时，事务提交；只要有一个没有回复成功，回滚
 *  节点：收到协调者的回应后，提交事务

问题主要有：

*  **同步阻塞：如果协调者没回应，会一直阻塞等待**
 *  **单点故障：协调者在第二阶段故障，所有节点需要等待**
 *  死锁：两个节点互相持有资源
 *  数据不一致：如果协调者在发送“提交事务信号时”宕机，一部分提交，一部分没提交。出现数据不一致问题

### 三阶段提交 ###

![Screenshot1521601979.png][]

主要解决了单点故障和阻塞的问题，**如果第一阶段所有的结点返回成功，那么有理由相信成功提交的概率很大**

*  1.协调者：发送消息给所有节点
 *  节点：如果认为当前自己可以完整执行事务，回复成功
 *  2.协调者：如果所有的节点都回复成功，通知所有节点进入预提交
 *  节点：收到消息执行事务并写好日志，回应给协调者成功或失败
 *  3.协调者：当所有节点都回复成功时，事务提交；只要有一个没有回复成功，回滚
 *  节点：收到协调者的回应后，提交事务；若超时未收到消息，默认提交成功（默认成功提交的几率很大）

### TCC ###

是应用层的一种补偿方法，需要代码实现。

1.  try:对业务系统做检测和预留
2.  confirm:执行业务流程，一般认为try成功，confirm一定成功
3.  cancel:事务遇到错误的回滚

举个例子，假入 Bob 要向 Smith 转账，思路大概是：  
我们有一个本地方法，里面依次调用

1.  首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。
2.  在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
3.  如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

### 消息队列传递 ###

将分布式事务分解成多个本地事务。具体做法：

1.  本地事务执行前，准备消息。
2.  执行完成，发送消息，否则取消消息。如果消息发送失败会尝试重新发送
3.  远端接受消息，并执行。

问题：

*  重复消息的问题：在消息消费方检查是否有一个同样的消息，如果有就抛弃
 *  消息发送失败：消费方提供一个check接口，接受到就返回确认

[Screenshot1521598291.png]: /images/20220529/133889812cb941058ba84d96670355cb.png
[Screenshot1521601979.png]: /images/20220529/b4e8f4fb4a0d49ef903202f0cd6843dc.png