分布式系统原理Day11-常见的分布式问题

迈不过友情╰ 2022-12-11 06:29 125阅读 0赞

### 常见的分布式问题 ###

*  分布式
 *   *  基本概念
     *  分布式优点
     *  分布式缺点
     *  CAP
     *  BASE
 *  分布式消息队列常见问题
 *   *  消息队列幂等性
     *   *  幂等性概念
         *  问题场景
         *  问题解决
     *  消息丢失
     *   *  生产者丢失消息
         *   *  问题解决
         *  消息队列丢失消息
         *   *  问题解决
         *  消费者丢失消息
         *   *  问题解决
         *  RabbitMQ消失丢失总结
         *  Kafka消息丢失
         *   *  问题场景
             *  问题解决
     *  消息乱序
     *   *  RabbitMQ消息乱序
         *   *  问题场景
             *  问题解决
         *  Kafka消息乱序
         *   *  问题场景
             *  问题解决
     *  消息积压
     *   *  问题场景
         *  问题解决
     *  消息过期失效
     *   *  问题场景
         *  问题解决
     *  消息队列写满
     *   *  问题场景
         *  问题解决
 *  分布式缓存常见问题
 *   *  Redis数据丢失
     *   *  问题场景
         *  问题解决
 *  分布式分库分表常见问题
 *   *  扩容
     *   *  问题场景
         *  问题解决
         *  问题总结
     *  唯一ID
     *   *  生产唯一ID的原则
         *  生成唯一ID的方式
         *   *  数据库自增ID
             *  UUID
             *  获取系统当前时间戳
             *  Twitter的Snowflake算法
             *  UIDGenerator算法
             *  Leaf-Snowflake算法
 *  分布式事务常见问题
 *   *  问题场景
     *  问题解决
     *   *  TCC方案
         *  Saga方案
         *  可靠消息最终一致性方案
         *  最大努力通知方案
         *  XA方案
     *  分布式事务总结

# 分布式 #

## 基本概念 ##

*  分布式系统是一种分工合作的工作方式
 *  若干独立计算机的集合,这些计算机对于用户来说就相当于一个单个系统
 *  分布式是指分布在不同地方的系统或者服务,将不同的业务分布在不同的地方,彼此是相互关联的

## 分布式优点 ##

*  **宏观层面:** 将多个功能模块在一起的功能模块进行拆分,来解耦服务间的调用
 *  **微观层面:** 将模块提供的服务分布到不同的机器或者容器里,来扩大服务力度

## 分布式缺点 ##

*  架构设计异常复杂,学习成本高
 *  运维部署和维护成本显著增加
 *  多服务之间的链路变长,开发排查问题难度增大
 *  环境高可靠性问题
 *  数据幂等性问题
 *  数据顺序问题

## CAP ##

*  **CAP理论:** CAP三个字母分别代表了分布式系统中三个相互矛盾的属性:
    
     *  **Consistency:** 一致性 **.CAP**理论中的副本一致性特指强一致性
     *  **Availablity:** 可用性. 系统在出现异常时已经可以提供服务
     *  **Partition Tolerance:** 分区容错性. 系统可以对网络分区这种异常情况进行容错处理

## BASE ##

*  **BASE**理论是指:
    
     *  **Basically Available -** 基本可用
        
         *  分布式系统在出现故障时,允许损失部分功能,保证核心功能可用
         *  比如电商网站交易付款出现问题时,商品依然可以正常浏览
     *  **Sofe state -** 软状态
        
         *  由于不要求强一致性,所以**BASE**理论允许系统中存在中间状态,即软状态.这个状态不影响系统可用性
         *  比如订单中的“支付中”,“数据同步中”等状态,待数据最终一致后状态改为“成功”状态
     *  **Eventually consistent -** 最终一致性
        
         *  经过一段时间后,所有节点数据都会达到一致
         *  比如订单中的“支付中”状态,最终会变成“支付成功”或者“支付失败”状态,使订单状态与实际交易结果达成一致,但是需要一定的延迟和等待
 *  **BASE**理论是对**CAP**中**AP**的扩展,通过牺牲强一致性来获得可用性. 当出现系统故障时允许部分功能不可用但是要保证核心功能可用,允许数据在一段时间内是不一致的,但是最终要达到一致状态
 *  满足**BASE**理论的事务叫作柔性事务

# 分布式消息队列常见问题 #

*  **分布式消息队列:** 将消息队列里面的消息分摊到多个节点机器或者容器上,所有节点的消息队列之和就包含了所有的消息

## 消息队列幂等性 ##

### 幂等性概念 ###

*  **幂等性:** 无论多少次操作和第一次的操作结果一样

### 问题场景 ###

*  **RabbitMQ, RocketMQ, Kafka**消息队列中间件都有可能出现消息重复消费问题.这个问题不是消息队列本身保证的,需要框架开发人员保证
 *  **Kafka保证消息队列的幂等性:**
    
     *  Kafka中有一个偏移量的概念,代表着消息的序号
     *  每条消息写到消息队列都会有一个偏移量
     *  消费者消费了数据之后,每过一段固定的时间,就会将消费过的消息的偏移量提交一下,表示已经消费过了,下次消费就从偏移量后面开始消费
 *  **问题:** 当消费完消息之后,还没来得及提交偏移量,系统就被关机了,那么未提交偏移量的消息则会被再次消费
 *  **示例:**

>  *  队列中的数据A, B, C, 对应的偏移量分别为100, 101, 102, 都被消费者消费.但是只有数据A的偏移量100提交成功,另外两个偏移量因为系统重启而导致未能及时提交  
>     ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center]
>  *  重启后,消费者又获取偏移量100以后的数据,从偏移量101开始获取消息,这样导致数据B和数据C被重复消费  
>     ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 1]

### 问题解决 ###

*  **微信支付结果通知场景:**
    
     *  微信官方文档上说明了微信支付通知结果可能会推送多次,需要开发者自行保证幂等性
     *  第一次可以直接修改订单状态,比如将订单状态由“支付中”修改为“支付成功”
     *  第二次就根据订单状态来判断,如果不是“支付中”,则不进行订单处理逻辑
 *  **插入数据库场景:**
    
     *  每次插入数据时,先检查一下数据库中是否存在这条数据的主键**ID,** 如果主键**ID**已经存在,则进行更新操作
 *  **写Redis场景:**
    
     *  **Redis**的**Set**操作具有天然的幂等性,不用考虑**Redis**写数据的幂等性问题
 *  **其余业务场景解决方案:**
    
     *  生产者发送每条数据时,增加一个全局唯一**ID.** 每次消费时,先去**Redis**中查询是否存在这个**ID,** 如果没有,则进行正常的消息处理,并且将这个**ID**保存到**Redis**中. 如果Redis中已经有这个**ID,** 说明之前已经消费过,就不需要重复处理这条消息

## 消息丢失 ##

*  **问题:** 比如在订单下单,支付结果通知,扣费相关出现消息丢失问题,可能会造成大量损失
 *  消息队列不能保证不会发生消息丢失,主要有三种场景会导致消息丢失:
    
     *  **在生产者存放消息的过程中丢失消息**
     *  **在消息队列传递消息的过程中丢失消息**
     *  **在消费者消费消息的过程中丢失消息**  
        ![\-][-]

### 生产者丢失消息 ###

*  生产这在存放消息的过程中丢失消息  
    ![在这里插入图片描述][20200930035732268.png_pic_center]

#### 问题解决 ####

*  **confirm机制:** 异步方式,推荐使用
    
     *  可以使用**confirm**机制来解决同步机制的性能问题
        
         *  每次生产者发送的消息都会分配一个唯一的**ID**
         *  如果写入到了**RabbitMQ**中,则**RabbitMQ**会回传一个**ack**消息,说明这个消息接收成功
         *  如果**RabbitMQ**没有能够接收处理这个消息,则回调**nack**接口,说明需要重试发送消息
     *  也可以自定义超时时间和消息**ID**来实现超时等待后重试机制
        
         *  但是可能会出现调用**ack**接口失败
         *  消息会被发送两次,这个时候就需要保证消费者消费消息的幂等性问题
 *  **事务机制:** 同步方式,不推荐使用
    
     *  对于**RabbitMQ**来说,生产者发送数据之前开启**RabbitMQ**的事务机制**channel.txSelect**
     *  如果消息没有进入队列,则生产者产生异常报错,并进行回滚**channel.txRollback,** 然后重试发送消息
     *  如果收到了消息,则可以提交事务**channel.txCommit**
     *  这样可以很好解决消息丢失问题,但是是一个同步操作,会影响性能
 *  **confirm机制和事务机制的比较:**
    
     *  **confirm**机制是异步接收通知,可能会有接收不到通知的情况,需要考虑接收不到通知的场景
     *  事务机制是同步操作,提交事务后会被阻塞到直到提交事务完成为止

### 消息队列丢失消息 ###

*  消息队列的消息可以存放到内存中,或者将内存中的消息存放到硬盘,比如数据库中,一般情况下,都是内存和硬盘中都存有消息
    
     *  如果消息队列的消息只是存放在内存中,那么当机器重启,消息就全部消失
     *  如果消息队列的消息存放在硬盘中,那么可能会有一种极端情况: 将内存中的数据转换到硬盘的过程中,消息队列出现问题,未能消息持久化到硬盘  
        ![在这里插入图片描述][20200930080051919.png_pic_center]

#### 问题解决 ####

*  创建**Queue**时将这个**Queue**设置为持久化
 *  发送消息的时候将消息的**deliveryMode**设置为**2**
 *  开启生产者**confirm**模式,重试发送消息

### 消费者丢失消息 ###

*  消费者获取到消息数据还未进行消息处理时,结果进程因为异常退出,这时,消费者没有机会再次拿到消息  
    ![在这里插入图片描述][20200930080500165.png_pic_center]

#### 问题解决 ####

*  关闭**RabbitMQ**的自动**ack,RabbitMQ**的自动**ack**会在每次生产者将消息队列写入消息队列后,就自动回传一个**ack**给生产者
 *  消费者处理完消息再主动**ack,** 通知消息队列处置完成
 *  **问题:** 这种主动**ack**有什么问题? 如果主动**ack**出现异常怎么处理?
    
     *  会存在消息重复消费问题,这时候需要做幂等处理
 *  **问题:** 如果这条消息一直被重复消费怎么处理?
    
     *  需要加上重试次数的监测,如果重试超过一定次数则将消息丢失,记录到异常表或者发送异常通知开发人员

### RabbitMQ消失丢失总结 ###

*  **RabbitMQ**丢失消息的处理方案:
    
     *  生产者丢失消息
        
         *  开启**confirm**确认机制
         *  开启**RabbitMQ**事务
     *  消息队列丢失消息
        
         *  开启**RabbitMQ**持久化
     *  消费者丢失消息
        
         *  关闭**RabbitMQ**自动**ack,** 修改为手动**ack**

### Kafka消息丢失 ###

#### 问题场景 ####

*  Kafka的某个节点broker宕机了,重新选举写入的节点leader
 *  如果写入的节点leader宕机了,follwer还有些数据未同步完成,则follower成为leader后,消息队列会丢失一部分数据

#### 问题解决 ####

*  给**topic**设置**replication.factor**参数,值必须大于**1,** 要求每个**partion**必须至少有**2**个副本
 *  给**Kafka**服务端设置**min.insyc.replicas**必须大于**1,** 表示一个**leader**至少同一个**follower**保持通信

## 消息乱序 ##

*  用户先下单成功,然后取消订单,如果顺序颠倒,那么最后数据库中还是会有一条下单成功的订单

### RabbitMQ消息乱序 ###

#### 问题场景 ####

*  生产者向消息队列中按照顺序发送了**2**条消息.消息**1**是增加数据**A,** 消息**2**是删除数据**A**
 *  期望结果: 数据**A**被删除
 *  如果出现**2**个消费者,消费顺序为消息**2**和消息**1,** 那么最后的处理结果是增加了数据**A**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 2]

#### 问题解决 ####

*  将**RabbitMQ**中的**Queue**进行拆分,创建多个内存**Queue,** 消息**1**和消息**2**进入同一个队列**Queue**
 *  创建多个消费者,每一个消费者对应一个**Queue**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 3]

### Kafka消息乱序 ###

#### 问题场景 ####

*  创建一个**topic,** 有**3**个**partion**
 *  创建一条订单记录,以订单**ID**作为**key,** 订单相关的消息都丢到同一个**partion**中,同一个生产者创建的消息,顺序是正确的
 *  为了快速消费消息,会创建多个消费者去处理消息,而为了提高效率,每个消费者可能会创建多个线程来并行获取消息以及处理消息,处理消息的顺序可能会因此错乱  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 4]

#### 问题解决 ####

*  线程获取消费者信息时创建多个队列**Queue,** 利用多个内存**Queue,** 每个线程消费一个**Queue**
 *  具有相同**key**的消息,进入同一个**Queue**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 5]

## 消息积压 ##

*  **消息积压:** 消息队列中有很多消息来不及消费

### 问题场景 ###

*  **问题场景1:** 消费端出了问题,比如消费者宕机,没有消费者消费,导致消息在队列中不断积压
 *  **问题场景2:** 消费端出了问题,比如消费者消费的速度太慢,导致消息不断积压
 *  **示例:**
    
     *  比如线上正在做订单活动,下单全部走消息队列,如果消息不断积压,订单都没有下单成功  
        ![在这里插入图片描述][20201002112053518.png_pic_center]

### 问题解决 ###

*  重构消费者代码,确保后续消费速度恢复或者尽可能加快消费的速度
 *  关闭现有消费者,临时建立好原先**5**倍的队列**Queue**的数量,临时建立好原先**5**倍数量的消费者
 *  将堆积的消息全部转入临时的**Queue,** 让临时的消费者来消费这些**Queue**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 6]

## 消息过期失效 ##

### 问题场景 ###

*  **RabbbitMQ**可以设置消息过期时间,如果消息超过一定的时间还没有被消费,就会被**RabbitMQ**清理  
    ![在这里插入图片描述][2020100410590324.png_pic_center]

### 问题解决 ###

*  准备好批量重导任务程序
 *  手动将消息闲时批量重导  
    ![在这里插入图片描述][20201004110049413.png_pic_center]

## 消息队列写满 ##

### 问题场景 ###

*  当消息队列因为消息积压的问题导致消息队列写满时,消息队列就不能接收更多的消息,此时生产者生产的消息将会被丢弃

### 问题解决 ###

*  判断哪些是无用的消息 **.RabbitMQ**中可以进行**Purge Message**操作
 *  如果是有用的消息,就要将消息快速消费,然后将消息内容保存到数据库中
 *  准备好重导任务程序将转存在数据库中的消息重导到消息队列
 *  手动将消息闲时重导

# 分布式缓存常见问题 #

*  在频繁访问数据库的场景中,因为访问磁盘**I/O**的速度是很慢的,通常会在业务层和数据层之间加入一套缓存机制,来分担数据库的访问压力
 *  在高并发的情况下,数据库还会对数据进行加锁,导致数据库的访问速度更慢
 *  分布式缓存通常使用**Redis,** 可以提供分布式缓存服务

## Redis数据丢失 ##

*  **哨兵机制:** 在**Redis**中,可以使用哨兵机制实现集群的高可用
    
     *  **集群监控:** 负责主副进程的正常工作
     *  **消息通知:** 负责将故障信息报警给运维人员
     *  **故障转移:** 负责将主节点转移到备用节点上
     *  **配置中心:** 通知客户端更新主节点地址
     *  **分布式:** 有多个哨兵分布在每个主备节点上,互相协同工作
     *  **分布式选举:** 需要大部分哨兵同意,才可以进行切换
     *  **高可用:** 即使部分哨兵节点宕机了,哨兵集群还可以正常工作

### 问题场景 ###

*  当主节点发生故障时,需要进行主备切换,可能会导致数据丢失
    
     *  **异步复制数据:** 主节点异步同步数据到备用节点的过程中,主节点宕机,会导致有部分数据未同步到备用节点. 此时备用节点又被选举为主节点,这就导致有部分数据丢失
     *  **脑裂:**
        
         *  脑裂是指主节点所在的机器脱离了集群网络.这时哨兵选举了新的备用节点作为主节点.这时候就导致有两个不同的主节点在同时工作,导致副节点数据不一致
         *  脑裂导致数据丢失是指在脑裂问题发生后,客户端还没有来得及切换到新的主节点,连的还是第一个主节点,这样有部分数据还是写入到了第一个主节点中,新的主节点中没有这部分数据.等到第一个主节点恢复后,会清空自身的数据然后作为备用节点连接到集群环境中,重新从主节点复制数据. 这就导致有部分数据丢失

### 问题解决 ###

*  配置**min-slave-to-write=1,** 表示至少有一个备用节点
 *  配置**min-slave-max-lag=10,** 表示数据的复制和同步的延迟不能超过**10s.** 这样保证最多丢失**10s**的数据

# 分布式分库分表常见问题 #

## 扩容 ##

*  扩容包括分库,分表,水平拆分和垂直拆分
 *  **分库:**
    
     *  因为一个数据库支持的最高并发访问数是有限的,可以将一个数据库的数据拆分到多个数据库中,这样可以增加最高并发访问数
 *  **分表:**
    
     *  因为一张表的数据量太大,即使使用索引查询性能也很低.这时可以将一张表的数据拆分成多张表.在查询时,只用拆分后的某一张表进行查询,这样可以明显提高SQL的查询性能
 *  **水平拆分:**
    
     *  将一个表的数据拆分到多个数据库,每个数据库中的表结构不变,使用多个数据库承担更高的并发
     *  比如订单表中每个月都会有大量数据,每个月都可以进行水平拆分,将上个月的数据存放到另一个数据库中
 *  **垂直拆分:**
    
     *  将一个有很多字段的表,拆分成多张表到同一个库或者多个库上面
     *  高频访问字段放到一张表,低频访问字段放到另外一张表
     *  利用数据库缓存来缓存高频访问的行数据
     *  比如将一张有很多字段的订单表拆分成几张表分别存放不同的字段,每个表中可以存在冗余字段
 *  **分库分表的方式:**
    
     *  根据租户来分库分表
     *  利用时间范围来分库分表
     *  利用**ID**取模来分库分表
 *  **分库分表的优点:**
    
     *  增加了数据库承受的并发量
     *  磁盘的使用率大大降低
     *  单表的数据量大大减少
     *  **SQL**的执行效率明显提升

### 问题场景 ###

*  分库分表是运维层面需要完成的事情,有时候会采取凌晨宕机来进行升级,可能会出现升级失败,则需要回滚

### 问题解决 ###

*  **双写迁移方案:** 迁移时,新数据的增删改操作在新数据和老数据都做一遍
 *  使用分库分表工具**Sharding-jdbc**来完成分库分表的工作
 *  使用程序来对比两个数据库的数据是否一致,直到数据一致

### 问题总结 ###

*  **分库分表引入的新问题:**
    
     *  **水平拆分:**
        
         *  跨库的关联查询性能差
         *  数据库多次扩容,维护量大
         *  跨分片的事务一致性难以保证
     *  **垂直拆分:**
        
         *  依然存在单表的数据量过大的问题
         *  部分表无法关联查询,只能通过接口聚合的方式解决.提升的开发的复杂度
         *  分布式事务处理复杂

## 唯一ID ##

*  如果要做分库分表,则必须做到表的主键**ID**是全局唯一的
    
     *  比如有一张订单表,被分到A库和B库,如果两张订单表的ID都是从1开始递增,就会导致很多订单ID都是重复的,那么查询订单数据时就会发生错乱
 *  分库的一个期望结果就是将访问数据库的次数分摊到其余的数据库
    
     *  有些场景是需要均匀分摊的,那么数据插入到多个数据库时就需要交替生成唯一的ID来保证请求均匀分摊到所有数据库

### 生产唯一ID的原则 ###

*  全局唯一性
 *  趋势递增
 *  单调递增
 *  信息安全

### 生成唯一ID的方式 ###

#### 数据库自增ID ####

*  **数据库自增ID:** 数据库每次生成一条记录,数据的**ID**自增**1**
 *  **缺点:**
    
     *  多个数据库的ID可能重复. 不可以作为分库分表的数据ID生成方式
     *  信息不安全

#### UUID ####

*  适用于**UUID**的唯一**ID**生成方式
 *  **缺点:**
    
     *  **UUID**太长,占用空间大
     *  不具备有序性. 作为主键,在写入数据时,不能产生有顺序的append操作,只能进行insert操作,导致读取整个B+树的节点到内存,插入记录后将整个节点写回磁盘,当记录占用的空间很大的时候,性能很差

#### 获取系统当前时间戳 ####

*  获取当前系统的时间戳作为数据库数据的主键**ID**
 *  **缺点:**
    
     *  在高并发的环境下 **,1ms**的时间内可能会生成多个重复的**ID,** 导致数据主键**ID**重复
     *  信息不安全

#### Twitter的Snowflake算法 ####

*  **雪花算法Snowflake:** 分布式**ID**生成算法 **,64**位的**long**型**ID,** 分为**4**个部分
    
     *  使用**1**位作为符号位,确定为**0,** 表示正
     *  使用**41**位作为毫秒数
     *  使用**10**位作为机器的**ID :** 高**5**位是数据中心**ID,** 低**5**位是机器**ID**
     *  使用**12**位作为毫秒内的序列号, 意味着每个节点每秒可以产生**4096(212)** 个**ID**  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 7]
 *  **优点:**
    
     *  毫秒数在高位,自增序列在低位,整个**ID**都是趋势递增的
     *  不依赖数据库等第三方系统,以服务的方式部署,稳定性更高,生成**ID**的性能也非常高
     *  可以根据自身业务特性分配字节**bit**位数,灵活性高
 *  **缺点:**
    
     *  强依赖机器时钟,如果机器上时钟回拨,会导致生成重复**ID**或者服务处于不可用状态

#### UIDGenerator算法 ####

*  **UIDGenerator算法:**
    
     *  基于**Snowflake**优化的分布式**ID**生成算法
     *  借用未来时间和双**Buffer**来解决雪花算法**Snowflake**生成**ID**的时钟回拨和生成性能问题,同时结合**MySQL**来进行**ID**分配  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 8]

#### Leaf-Snowflake算法 ####

*  **Leaf-Snowflake算法:**
    
     *  首先通过代理服务访问数据库获取一批雪花算法**Snowflake**生成的**ID**
     *  然后使用双缓冲机制,当前一批**ID**使用**10%** 时,再访问数据库获取新的一批**ID**缓存起来,等上一批**ID**使用完毕后立即使用  
        ![\-][- 1]
 *  **优点:**
    
     *  **Leaf**服务可以很方便地进行线性扩展,性能能够完全支撑大部分的业务场景
     *  生成的唯一**ID**是趋势递增的**8**字节的**64**位数字,满足数据库存储的主键要求
     *  容灾性高 **,Leaf**服务内有号段缓存,即使数据库短时间宕机 **,Leaf**仍能正常对外提供服务
     *  可以自定义**max\_id**的大小,可以很方便的将业务从原有的**ID**上迁移过来
     *  即使数据库宕机 **,Leaf**仍能持续发送一段时间的号段,偶尔的网络波动不会影响下个号段的更新
 *  **缺点:**
    
     *  信息不安全,生成的唯一**ID**是趋势递增的,不具备随机性,容易暴露发号数量的信息

# 分布式事务常见问题 #

*  **事务:**
    
     *  事务可以大概的理解为一件事情要么全部做完,要么这件事情一点都没做,没有发生一样
     *  在分布式环境中,存在着各个服务之间的相互调用,链路可能很长,如果有任何一方执行出错,那么需要回滚涉及到的其余服务的相关操作
     *  比如订单下单成功,然后需要调用发送的代用劵接口,如果此时支付接口调用失败,则需要退回调用的代用劵,并且将订单的状态设置为异常状态

## 问题场景 ##

*  如何保证分布式事务正确有效执行?

## 问题解决 ##

*  **分布式事务的几种方式:**
    
     *  TCC方案
     *  SAGA方案
     *  可靠消息最终一致性方案
     *  最大努力通知方案
     *  XA方案

### TCC方案 ###

*  **TCC方案:** Try-Confirm-Cancel
    
     *  **Try阶段:** 对各个服务的资源做检测以及对资源进行锁定或者预留
     *  **Confirm阶段:** 各个服务中执行实际的操作
     *  **Cancel阶段:** 如果任何一个服务的业务方法执行出错,需要将之前操作成功的步骤进行回滚
 *  **应用场景:**
    
     *  和支付以及交易相关,必须保证资金正确的场景
     *  对于一致性要求很高的场景
 *  **缺点:**
    
     *  因为需要编写很多补偿逻辑的代码,并且代码难以维护,不建议在其余场景中使用

### Saga方案 ###

*  **Saga方案:** 如果业务流程中的每个步骤只要有一个失败了,就要补偿前面操作成功的步骤
 *  **应用场景:**
    
     *  业务流程长,业务流程多的场景
     *  参与者包含其余公司或者遗留系统服务的场景
 *  **优点:**
    
     *  第一阶段提交本地事务,无锁,高性能
     *  参与者可以异步执行,高吞吐
     *  补偿服务易于实现
 *  **缺点:**
    
     *  不保证事务的隔离性

### 可靠消息最终一致性方案 ###

*  利用消息中间件**RabbitMQ**来实现消息事务  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 9]
 *  **第一步:** **A**系统发送一个消息到消息队列,消息队列将消息状态标记为**preapred**准备状态的半消息,该消息无法被订阅
 *  **第二步:** 消息队列响应**A**系统,回复**A**系统已经收到消息
 *  **第三步:** **A**系统执行本地事务
 *  **第四步:** 如果**A**系统执行本地事务成功,就会将**prepared**消息状态修改为**commit**提交事务消息状态 **,B**系统就可以订阅该消息
 *  **第五步:** 消息队列也会定时轮询所有的**prepared**准备状态的消息,回调**A**系统,获取**A**系统中对应消息的本地事务的执行情况,决定继续等待还是回滚
 *  **第六步:** **A**系统检查本地事务的执行结果
 *  **第七步:** 根据**A**系统本地事务的执行结果给消息队列发送信号: 如果**A**系统执行本地事务成功,那么消息队列接收到**commit**信号;如果**A**系统执行本地事务失败,那么消息队列接收到**Rollback**信号
 *  **B**系统接收到消息后,开始执行本地事务,如果执行失败,就自动不断重试直到成功. 或者**B**系统也可以采取回滚的方式,同时也要采取其余的方式通知**A**系统也要进行回滚. 并且**B**系统要保证幂等性

### 最大努力通知方案 ###

*  **最大努力通知方案:**
    
     *  **A**系统执行本地事务完成后,发送消息到消息队列
     *  消息队列将消息持久化
     *  如果**B**系统执行本地事务失败后,最大努力服务会定时尝试重新调用**B**系统,尽最大努力让**B**系统重试,如果重试多次还是失败就放弃

### XA方案 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 10]

*  事务管理器负责协调多个数据库的事务,先查询各个数据库是否准备完成:
    
     *  如果准备完成,就在数据库中执行操作
     *  如果存在任何一个数据库没有准备完成,就对事务进行回滚
 *  适合单体应用,不适合微服务架构. 因为每个服务只能访问自己的数据库,不允许交叉访问其余微服务的数据库

## 分布式事务总结 ##

*  在支付,交易的场景中,优先使用**TCC**方案
 *  在大型系统中,可以尝试使用消息事务和**Saga**方案
 *  单体应用使用**XA**两阶段提交就可以
 *  最大努力通知方案是先进行重试,看是否成功,如果没有成功就放弃

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/149dd93ed1694acbbeb52b3f7b015251.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/6cd46b83449d455a911a69fcf35c0dca.png
[-]: /images/20221123/d8d1e7c44ce34432b637dce222860d97.png
[20200930035732268.png_pic_center]: /images/20221123/70672ddb82534b1d9091eb1a7ae17676.png
[20200930080051919.png_pic_center]: /images/20221123/aa350508c94c4b3d9ed5bea2c52aa08e.png
[20200930080500165.png_pic_center]: /images/20221123/9f4ece6bdedc4d4fbe7ae63e299b4dd2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/9f689750c8d14ec9945cedf97d2fa00c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/b3591fe3cd8b4d088d6c48dcea47560c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/f76631ba371e4d51b8c816c794cf047b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/a08798c8c6b244bd979f08cbd64a7a15.png
[20201002112053518.png_pic_center]: /images/20221123/905c068009ab4884b1ac24372525435a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/cdb3c9cadd3944998ec2025be183faa2.png
[2020100410590324.png_pic_center]: /images/20221123/586d761dee0e493f97a39436959f9ffb.png
[20201004110049413.png_pic_center]: /images/20221123/baf9c025f4974cdc86009b9ffc7eb224.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221123/9cf2fc4781944f229114cd92fa72a3d2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221123/917de4c7e7bb45ed89f46b263979a34b.png
[- 1]: /images/20221123/b433b295ddcf4324b63b8cb9fcfa5dd6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221123/09b2182467ac4b76a45eecb2e6690313.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221123/7f5fda360c06485ebed0327ce0cf4e2b.png