有关分布式事务的小讨论

素颜马尾好姑娘i 2022-11-25 13:18 161阅读 0赞

### 文章目录 ###

*  CAP 定理
 *  raft算法实现一致性
 *   *  领导选举
     *  日志复制
     *  分区容错
 *  BASE理论
 *  分布式事务解决方案
 *   *  2PC模式
     *   *  协调者是一个单点，存在单点故障问题
         *  新协调者的缺陷
     *  3PC模式
     *  柔性事务-TCC 事务补偿型方案
     *  柔性事务- 最大努力通知型方案
     *  柔性事务- 可靠消息+最终一致性方案（异步确保型）
 *  参考

# CAP 定理 #

*  一致性（Consistency） 在分布式系统中的所有数据备份，在同一时刻是否同样的值（等同于所有节点访问同一份最新数据副本）
 *  可用性（Availability） 在集群一部分节点故障后，集群整体是否还能响应客户端的读写请求（对数据更新具备高可用性）
 *  分区容错性（Partition Tolerance） 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区。分区容错的意思是，区间通信可能失败，需要容忍错误。

**CAP原则即为 以上三要素只能同时实现两点，不能三者兼顾，对于多数大型互联网的应用场景，主机众多，部署分散，而现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到99.99…% 即保证AP，舍弃C永远要满足分区容错**

*  AP（Eureka、Nacos）  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70]
 *  CP（Zookeeper、Consul）  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70 1]

--------------------

# raft算法实现一致性 #

[http://thesecretlivesofdata.com/raft/][http_thesecretlivesofdata.com_raft]

*  所有节点有三种状态、`跟随者`、`候选者`、`领导者`
 *  如果`跟随者`不能感知到`领导者`，他将变成一个`候选者`，然后向其他`跟随者`请求投票给自己
 *  其他`跟随者`回应他们的投票
 *  如果`候选者`获得了超过半数的选票，他将变为`领导者`，以上这个过程为 `领导选举`

--------------------

*  系统的所有改变都需要通过`领导者`
 *  每一个改变都被当作一个`entry`放入`领导者节点日志`，数据不会被更新，因为`entry`并没有被提交
 *  提交`entry`的第一步，是`领导者`先把其复制给其他`跟随者`，然后`领导者`待到大多数`跟随者`将`entry`写入后更新数据
 *  然后`领导者`通知`跟随者` `entry`已经提交，至此，集群完成了一致性操作。以上这个过程为 `日志复制`

## 领导选举 ##

*  有两个时限限制设置控制领导选举
 *  第一个是`选举时限`，指的是`跟随者`等待变为`候选者`的时间，随机分布在`150ms-300ms`
 *  在`选举时限`时间过去之后，一个`跟随者`变为`候选者`并开启了一个新的选举，首先他会自己投自己一票
 *  然后发送投票请求给其他`跟随者`投票，如果其他`跟随者`在这次选举中还没有投过票，就把票投给他，并且重置`选举时限`时间
 *  一旦一个`候选者`获得了大多数票数，他成为`领导者`
 *  然后`领导者`将增量条目发送给它的`跟随者`，这些消息在内部发送，并且在规定的`心跳时间`内，跟随者会响应每条增量条目
 *  `跟随者`每次接受心跳都会重置`选举时限`时间
 *  在下一个`跟随者`停止收到`领导者`的心跳，成为`候选者`之前，该次选举结果会持续
 *  如果同时有两个候选者进行选举并且获得了相同票数，则会重新开启一轮`选举时限`，产生新的`候选者`进行选举

## 日志复制 ##

*  一旦`新领导`被选举出来，需要复制所有的改变给其他`跟随者`，通过`心跳机制`完成`增量复制`
 *  首先客户端把改变发给`领导者`，`领导者`将改变放入日志，在下一次`心跳`的时候将改变发送给`跟随者`
 *  `entry`被提交一旦`大部分跟随者`确认收货，然后响应客户端

## 分区容错 ##

每个分区都会产生一个领导，最后根据选举代数高的作为最新领导。如果每个分区节点数量相同，选不出领导，直接响应客户端集群当前不可用

# BASE理论 #

*  基本可用（basically available） 是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性）需要注意的是，基本可用绝不等价于系统不可用
    
     *  响应时间上的损失。 正常情况下，搜索引擎需要在0.5s内返回给用户相应的查询结果，但是由于故障，查询结果响应时间增加到2-3秒
     *  功能上的损失 购物网站在购物高峰时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面
 *  软状态（soft state） 指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据有多个副本，允许不同副本同步的延时就是 软状态的体现。MySQL replication的异步复制也是一种体现
 *  最终一致性（eventual consistency） 指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况

# 分布式事务解决方案 #

## 2PC模式 ##

数据库支持的2pc【2 phase commit 二阶提交】，又叫做 XA Transaction MYSQL从5.5版本开始支持，SQL server 2005开始支持，Oracle7开始支持 XA是一个两阶段提交协议，该协议分为以下两个阶段：

*  事务协调器要求每个涉及到事务的数据库预提交（precommit）此操作，并反映是否可以提交
 *  事务协调器要求每个数据库提交数据 其中如果任何一个数据库否决此次提交，那么所有数据库都会被要求回滚他们在此事务中的那部分信息  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70_pic_center]  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70_pic_center 1]

2PC 是一个同步阻塞协议，第一阶段协调者会等待所有参与者响应才会进行下一步操作，第一阶段的协调者有超时机制，假设因为网络原因没有收到某参与者的响应或某参与者挂了，那么超时后就会判断事务失败，向所有参与者发送回滚命令。

第二阶段协调者的没有超时机制，只能不断重试！

### 协调者是一个单点，存在单点故障问题 ###

*  协调者在发送准备命令之前挂了，等于事务还没开始
 *  发送准备命令之后挂了，有些参与者等于都执行了处于事务资源锁定的状态。不仅事务执行不下去，还会因为锁定了一些公共资源而阻塞系统其它操作。
 *  发送回滚事务命令之前挂了，事务执行不下去，且在第一阶段那些准备成功参与者都阻塞着。
 *  发送回滚事务命令之后挂了，命令发出去了，很大的概率都会回滚成功，资源都会释放。但是如果出现网络分区问题，某些参与者将因为收不到命令而阻塞着。
 *  发送提交事务命令之前挂了，所有参与者都阻塞着
 *  发送提交事务命令之后挂了，命令发出去了，很大概率都会提交成功，然后释放资源，但是如果出现网络分区问题某些参与者将因为收不到命令而阻塞着。

### 新协调者的缺陷 ###

每个参与者自身的状态只有自己和协调者知道，所以当老协调者和某些参与者一起挂掉之后，新协调者不知道这些挂掉的参与者之前的状态，也无法继续做决定，可能会出现数据不一致的情况。

特点：

*  2PC 是一种尽量保证强一致性的分布式事务
 *  同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率低
 *  存在单点故障问题，在极端条件下存在数据不一致的风险。
 *  XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低
 *  性能不理想，特别是在交易下单链路，并发量通常很高，XA无法满足高并发场景
 *  XA目前在商业数据库支持的比较理想，在MySQL数据库中支持的不太理想，MySQL的XA实现，没有记录prepare阶段的日志，主备切换导致主库与备库数据不一致
 *  许多nosql也没有支持XA，这让XA的应用场景变得十分狭隘

## 3PC模式 ##

3PC 包含了三个阶段，分别是准备阶段、预提交阶段和提交阶段：CanCommit、PreCommit 和 DoCommit。

3pc准备阶段=了解参与者运行状况，是否可以参加事务，而不会直接执行事务  
3PC预提交=2PC准备阶段  
3PC提交=2PC提交  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70_pic_center 2]  
引入了超时机制，参与者就不会傻等了，如果是等待提交命令超时，那么参与者就会提交事务了，因为都到了这一阶段了大概率是提交的，如果是等待预提交命令超时，那该干啥就干啥了，反正本来啥也没干。

然而超时机制也会带来数据不一致的问题，比如在等待提交命令时候超时了，参与者默认执行的是提交事务操作，但是有可能执行的是回滚操作，这样一来数据就不一致了。

## 柔性事务-TCC 事务补偿型方案 ##

*  刚性事务：遵循ACID，强一致性
 *  柔性事务：遵循BASE，最终一致性 与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致

--------------------

TCC 是业务层面的分布式事务  
TCC 指的是Try - Confirm - Cancel。

*  Try 指的是预留，即资源的预留和锁定，注意是预留。
 *  Confirm 指的是确认操作，这一步其实就是真正的执行了。
 *  Cancel 指的是撤销操作，可以理解为把预留阶段的动作撤销了。

一阶段：prepare行为，调用自定义的prepare逻辑  
二阶段：commit行为，调用自定义的commit逻辑  
三阶段：rollback行为，调用自定义的rollback逻辑 TCC支持把自定义的分支事务纳入全局事务的管理中  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70_pic_center 3]  
TCC 对业务的侵入较大和业务紧耦合，撤销和确认操作的执行可能需要重试，因此还需要保证操作的幂等。

## 柔性事务- 最大努力通知型方案 ##

按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时。比如：调用微信或者支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现。例如：MQ发送http请求，设置最大通知次数，达到通知次数后不再通知。 案例：银行通知、商户通知等（各大交易平台间的商户通知：多次通知、查询校对、对账文件），支付宝支付成功异步回调

## 柔性事务- 可靠消息+最终一致性方案（异步确保型） ##

业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正地发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送，只有在得到确认发送指令后，实时消息服务才会真正发送

# 参考 #

[分布式事务][Link 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70]: /images/20221124/50fcec4b5f074111a1bbe797ec9c878d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70 1]: /images/20221124/56c2fc22066441eaa60fc9bec0244cb0.png
[http_thesecretlivesofdata.com_raft]: http://thesecretlivesofdata.com/raft/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221124/a1e8efd823ff4961b9759ea86ec40109.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221124/62eff8e9bc9942fab738454e322bb8b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221124/90ade17031404abf96348e973ffc00ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221124/90888688e2af45558466660dabe0c098.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzAwNDA2OTM1Ng==&mid=2453145405&idx=3&sn=f3f3f29618c9b9902393b33b1e4ef9a9&chksm=8cfd25bebb8aaca812cdfa377c03afc1e95a8833ff9215efaad3efa6ed21b40d3fa44e7f6f39&mpshare=1&scene=23&srcid=0815czEyeD9Rvkeg1W1iaVez&sharer_sharetime=1597917685634&sharer_shareid=44f7dd07216a00b50323ae3aa2dc9745#rd