分布式专题技术

Kyire丶

已于 2022-10-19 14:57:55 修改

阅读量1.1k

点赞数 1

文章标签：分布式数据库 redis

于 2022-07-26 23:25:52 首次发布

本文链接：https://blog.csdn.net/qq_43703196/article/details/125999428

版权

分布式专题面经

一、分布式ID的生成方案？

方案	描述	优点	缺点
UUID	UUID是通用唯一标识码的缩写，其目的是让分布式系统中所有元素都有唯一的辨识标志，无需中央控制器进行指定	① 降低全局节点的压力，主键生成速度快； ② 生成的主键全局唯一，跨服务器合并数据方便；	① UUID占用16个字符，空间占用大； ② UUID不是递增有序的数据，数据写入IO随机性大，索引效率下降；
数据库自增主键	MySQL数据库设置主键且自增	① Int和bigInt类型占用空间小，且数字类型索引的查询速度优于字符串索引类型； ② 主键自增，IO写入连续性好；	① 由于MySQL数据存储在磁盘中，导致其并发性能不高； ② 设置分布式ID要考虑数据库的分库分表，改造复杂； ③ 由于主键是自增的，数据容易泄露；
Redis自增	Redis计数器，incr命令实现原子性自增	Redis使用内存，并发性能好	① 由于是内存存储，数据易丢失 ② 自增，数据容易泄露
雪花算法	分布式ID经典解决方案	① 高性能高可用：生成时不依赖于数据库，完全在内存中生成。 ② 容量大：每秒中能生成数百万的自增ID。 ③ ID自增：存入数据库中，索引效率高	时钟回拨，有非常小的概率ID会重复

雪花算法

雪花算法共占用64位bit，其主要有以下4个部分组成

位	作用
符号位	`占用1bit，固定为0；` 因为二进制里第一个 bit 为如果是 1，那么都是负数，但是我们生成的 id 都是正数，所以第一个 bit 统一都是 0。
时间戳	`占用41bit`，可以支持69年的跨度
机器ID	`占用10bit`，记录工作机器 id，代表的是这个服务最多可以部署在 2^10 台机器上，也就是 1024 台机器。
序列号	`占用12bit`，用来记录同一个毫秒内产生的不同 id (每毫秒能够生成4095个ID，不算全0)

在这里插入图片描述

二、分布式锁

1、分布式锁的应用场景？

场景
① 系统是一个分布式系统 / 集群模式，仅靠Java的锁是锁不住的；
② 多个微服务共同操作一个共享资源。比如数据库中的唯一用户数据；
③ 同步访问，即多个进程共同操作共享资源；
④ 用分布式锁进行限流；

2、实现分布式锁的方式？

方式	原理	优点	缺点
redis	`1) LUA (SETNX命令 + expire键过期) + watch Dog机制 + LUA (删除时判断锁是不是自己要删的那把)` ① SETNX命令：全称为【SET key value if Not exists】，当且仅当key不存在时，才会设置并返回true；如果设置不成功则返回false，然后进入循环请求状态，直到获取到锁 (是否自旋可以自定义)；【根据是否设置key成功判断是否获取锁成功】 ② expire键过期： SETNX必须设置过期时间，原因是为了防止redis在SET成功后，突然宕机；如果不设置键过期时间，那么这个key永远都存在，其它微服务永远获取不到分布式锁； ③ watch Dog机制：保证成功获取到锁的微服务在没有执行结束前，一直保持持有分布式锁的状态；一旦expire达到过期时间，此时若系统还在执行，那么watch Dog就会帮助系统续上锁的过期时间； ④ 删除时判断锁：目的是确保删除的是自己持有的锁，防止误删了其它微服务的锁； `2) Redisson框架：提供了lock、unlock命令、分布式信号量等机制；`	① redis分布式锁完全基于内存，并发性能好，速度快； ② redis单线程IO多路复用，减少了多个线程创建时的开销，避免不必要的上下文切换以及资源竞争导致的锁开销； ③ redis提供了丰富的数据结构，全程hash操作，加锁释放锁速度快； ④ redis基于LUA脚本等，确保加锁与释放锁的原子性；	① redis只保证最终一致性，集群模式(主写从读)下主从同步会有延迟，分布式锁有丢失的可能性，故强一致性的业务不推荐用redis分布式锁，而是推荐Zookeeper分布式锁；
Zookeeper	前提：临时顺序节点： 1- 顺序 (规定怎么获得锁)：当多个客户端进行竞争分布式锁时，每个客户端都会在某个指定的唯一ZK节点下创建一个临时顺序节点；这个节点是递增的，规定越早创建临时顺序节点的客户端能够获取到锁 (即节点序号最小的获得锁) 2- 临时 (规定怎么释放锁)：当客户端与zookeeper集群断开连接时，临时顺序节点自动被删除 (释放锁)； `根据Zookeeper的临时顺序节点实现分布式锁` ① 客户端A连接到ZK，在指定的唯一节点下调用creat()方法创建名为"/业务ID/lock-"的临时顺序节点； ② 客户端A调用getChildren(“业务ID”)方法获取全部创建的临时顺序节点； ③ 客户端A获取到全部的临时顺序节点后，判断是否拿到了分布式锁： 1-如果发现自己创建的临时顺序节点是最小的，那么就认为该客户端A获取到了分布式锁； 2-若发现自己创建的临时顺序节点不是最小的，那么就监听比自己小的节点，当比自己小的节点删除以后，客户端A会收到watcher事件，此时再次判断自己的节点是不是最小的，如果是则获得锁；不是则重复这个过程，直到获取到锁；	① Zookeeper集群是基于CP模式的，它基于Zookeeper原子播送歇息，支持自动恢复与原子播送，能够实现`强一致性`；	① Zookeeper由于网络波动等，不能保证每次服务的可用性； ② 由于Zookeeper每次进行锁操作前都要创建若干节点，完成后还要删除节点，会浪费很多时间；在并发性能上不如redis，因为redis只是简单的数据内存存储删除操作；
MySQL	`根据MySQL的主键id唯一性实现分布式锁` ① 抢锁时，携带主键/唯一索引向表中插入数据； ② 抢锁成功：若数据库中，待插入的主键id不存在，则插入成功； ③ 抢锁失败：若插入的数据所在主键id已经存在，那么插入失败； ④ 释放锁：即删除插入的那个主键id所在行的数据；	① 分布式锁实现简单，锁的获取与释放完全是MySQL在控制；	① 若加上分布式锁后，事务执行过程中宕机，有死锁的风险； ② 没有锁过期时间，还是容易死锁； ③ 数据库若是单点操作，那么数据库一旦挂掉，整个业务系统都不可用；

三、限流策略

方式	原理	缺点
计数器	在指定的时间周期内设定访问量阈值，比如1分钟内，直到流量超过100次访问，那么就触发限流算法；待到下一个周期进行访问时，访问次数清零；	不能处理短期内的大并发请求
滑窗	滑窗是计数器限流算法的升级版；计数器限流算法比如在周期的最后几秒和下一个周期的前几秒突然出现大规模访问，计数器算法是处理不了的；因此引入滑窗限流法，时间周期不在固定，而是将原本的实际周期切分成多个小的时间窗口，分别维护每个小的时间窗口；	计数器的进阶
漏桶	漏桶容量 (访问阈值) = 漏桶的流出速度 (处理速度) × 可接受的等待时长 ①当请求速度小于漏桶的流出速度时，在漏桶容量范围内，可以按照漏桶的流出速度排队进行正常处理； ② 当请求速度大于漏桶的流出速度时，则触发限流策略；	不能处理短期内的大并发请求
令牌桶	准备一个初始已经存放了一定数量令牌的容器，同时系统以恒定的速率向令牌桶中持续放入令牌；客户端发送请求，要先取得令牌，拿到令牌才能有资格访问系统；当令牌桶满的时候，新生成的令牌会被抛弃，不放入桶中；由于令牌桶初始已经有了很多令牌，因此能够处理短时间内的大量请求；	漏桶进阶

四、你设计微服务时遵循什么原则？

原则	描述
单一职责原则	每个微服务能独立、有界限地工作，只关注自己的业务，做到高内聚；
服务自治原则	每个服务要能独立开发，独立测试、独立构建、独立部署、独立运行，与其它微服务解耦；
轻量级通信原则	每个微服务之间的调用是轻量级的，并且能够跨平台、跨语言；采用restful风格，消息队列等进行通信；
粒度进化原则	注意微服务粒度把控

五、分布式事务

1、分布式理论

1）CAP理论

CAP理论指的是：分区容错性（P）必须保证的前提下，一致性（C）与可用性（A）只能保证其中一个

A和C只能保证其一的原因：

如果保证了一致性（C），那我们就要保证客户端在任意时刻，在任意一个节点读到的值都是一致的；而可用性（A）是允许部分节点故障时，集群还能继续响应，那么就无法保证故障节点非故障节点之间的一致性了；反过来也是一样的道理，因此A和P无法共存；

CAP原理	描述
一致性 (Consistency)	在分布式系统的所有服务器节点中，在同一时刻都是同样的值；
可用性 (Availability)	在服务器集群中的一部分节点故障后，集群整体还能继续响应客户端的读写请求；
分区容错性 (Partition tolerance)	在分布式系统中遇到任何网络分区故障，系统依然能对外提供服务；

2）BASE理论

BASE理论是CAP理论的延伸，思想是：既然无法做到强一致性(CAP)，那么就保证弱一致性，即最终一致性；

Base理论在秒杀系统中，可以结合消息队列使用；

BASE理论	描述
基本可用 (Basically Available)	基本可用是指分布式系统在出现故障时，允许损失部分可用性 (例如响应时间、功能上的可用性)； eg：秒杀系统中，当流量高峰时，为了保护系统的整体可用性，将部分消费者引导到一个降级页面；
软状态 (Soft State)	软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。 eg：用户支付后，第三方支付系统返回给订单系统的这段时间，给用户显示"支付中"；
最终一致性 (Eventual Consistency)	最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。 eg：用户取消订单后，发送MQ消息，经过一段时间后，库存回滚；

3）一致性理论

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。

理论	描述
强一致性	读写操作后，能立刻看到更新过的数据
弱一致性	能容忍部分或者全部数据看不到
最终一致性	经过一段时间后，能够看到更新后的数据

2、分布式事务解决方案

模式	特点	描述
刚性事务	满足CP理论：一致性与分区容错性	① XA协议 (2pc、JTA、JTS、3pc)：由于同步阻塞，处理效率低，不适合大型网站分布式场景
柔性事务	满足AP(BASE)理论：基本可用，最终一致	① TCC/FMT、Saga (状态机模式、Aop模式)、本地事务消息、消息事务 (半消息)：结合业务改造，最终一致性，实现补偿接口，实现资源锁定接口，高并发，更适合长事务

3、刚性事务：XA协议

1）XA规范

在XA规范中有三个角色：应用程序、事务管理器、资源管理器

角色	作用
应用程序	业务层，定义哪些操作属于一个事务
事务管理器	接收【应用程序】的事务请求，对全局事务进行管理，管理事务分支状态，协调【资源管理器】处理，通知资源管理器哪些操作属于全局事务以及事务分支等
资源管理器	一般是数据库DB，也可以是消息队列MQ、文件系统等

XA规范主要定义了全局的事务管理器和局部的资源管理器之间的接口。XA接口是双向的系统接口，在事务管理器以及一个或多个资源管理器之间形成通信桥梁。
XA规范使用两阶段提交 (2pc) 协议来保证所有资源同时提交或回滚任何特定的事务；
XA是数据库的分布式事务，保证强一致性(CP)；在整个过程中，从prepare → commit → rollback的整个过程中，事务管理器一直把持着数据库的锁，如果有其他人要修改数据库的该条数据，就必须等待锁的释放，存在长事务风险；

2）两阶段式提交 (2pc)

协调者： 全局事务管理器
参与者： 局部资源管理器

阶段描述

阶段一：准备阶段 (投票阶段) 1）事务询问： 协调者 (事务管理器) 向所有参与者发送事务内容，询问是否可以执行提交操作，并开始等待各参与者 (资源管理器) 进行响应；

2）执行事务： 各参与者节点，执行事务操作，并将信息写入undo log日志与redo log日志 (注意：若成功这里其实每个参与者都已经执行了事务操作)；

3）各参与者向协调者反馈事务问询的响应： 成功执行返回Yes，否则返回No；

阶段二：提交阶段 (执行阶段) 1）提交事务：若所有参与者 (资源管理器) 均回复yes，那么执行事务提交操作；

① 发送请求： 协调者向所有的参与者发送Commit请求；

② 事务提交： 参与者收到Commit请求后，会正式的执行事务提交操作，并在完成提交操作之后，释放在整个事务执行期间占用的资源；

③ 反馈结果： 参与者在完成事务提交后，向协调者回复ACK消息；

④ 完成事务： 协调者收到全部参与者的提交ACK后，完成提交事务；

2）中断事务：若存在某一参与者向协调者发送No响应，或者等待超时；那么协调者就会中断事务；

① 发送回滚请求： 协调者向所有参与者发送rollback请求；

② 回滚： 参与者收到请求后，利用本地的undolog日志，执行rollback操作。并在回滚结束后释放该事务所占用的系统资源；

③ 反馈回滚结果： 参与者在完成回滚操作后，向协调者回复回滚ACK消息；

④ 中断事务： 协调者收到全部参与者的回滚ACK消息后，完成中断事务；

阶段	描述
阶段一：准备阶段 (投票阶段)	1）事务询问：协调者 (事务管理器) 向所有参与者发送事务内容，询问是否可以执行提交操作，并开始等待各参与者 (资源管理器) 进行响应； 2）执行事务：各参与者节点，执行事务操作，并将信息写入undo log日志与redo log日志 (注意：若成功这里其实每个参与者都已经执行了事务操作)； 3）各参与者向协调者反馈事务问询的响应：成功执行返回Yes，否则返回No；
阶段二：提交阶段 (执行阶段)	`1）提交事务：若所有参与者 (资源管理器) 均回复yes，那么执行事务提交操作；` ① 发送请求：协调者向所有的参与者发送Commit请求； ② 事务提交：参与者收到Commit请求后，会`正式的执行事务提交操作`，并在完成提交操作之后，`释放在整个事务执行期间占用的资源`； ③ 反馈结果：参与者在完成事务提交后，向协调者回复ACK消息； ④ 完成事务：协调者收到全部参与者的提交ACK后，完成提交事务； `2）中断事务：若存在某一参与者向协调者发送No响应，或者等待超时；那么协调者就会中断事务；` ① 发送回滚请求：协调者向所有参与者发送rollback请求； ② 回滚：参与者收到请求后，利用本地的undolog日志，执行rollback操作。并在`回滚结束后释放该事务所占用的系统资源`； ③ 反馈回滚结果：参与者在完成回滚操作后，向协调者回复回滚ACK消息； ④ 中断事务：协调者收到全部参与者的回滚ACK消息后，完成中断事务；

2pc的缺点

缺点
① 同步阻塞导致并发性能不高：本地事务 (参与者) 在全局事务 (事务管理器) 没 commit 或 callback前都是阻塞等待的，全局事务等待回复的时间由事务时间最长的那个本地事务决定；
② 单点故障导致高可用问题：由于协调者 (事务管理器) 是单点，一旦出现故障，每个参与者都无法释放事务资源，也无法完成事务提交；
③ 丢失消息导致的数据不一致问题：在2pc的第二阶段，协调者给所有参与者发送完Commit请求或者回滚请求后，出现网络崩溃，导致只有部分节点收到请求，并执行；此时整个分布式系统就会出现数据不一致现象；
④ 过于保守： 2pc协议没有设计较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。

在这里插入图片描述

3）三阶段式提交 (3pc)

3pc解决的问题

3pc解决的问题不能解决的问题

① 解决了协调者的单点故障，无法释放资源的问题：
针对2pc的同步阻塞与单点故障问题，3pc对于协调者与参与者都设置了超时时间，而2pc只有协调者才拥有超时机制；当进入第三阶段时，由于网络超时/网络分区等原因，如果第二阶段没有中断事务，虽然参与者没有收到commit或者abort响应，但是由于第二阶段的预提交所有参与者都回复了yes，他有理由相信：成功提交的几率很大；
② 由于解决了单点故障问题，从侧面上也降低了整个事务的组设时间与范围； ① 3pc依然无法解决数据不一致问题：
最后一个阶段，由于网络问题等，部分参与者收到了协调者发送的doCommit请求或者rollback请求，有一部分没有收到，就会导致数据不一致现象；

对协调者设置超时时间，避免了由于协调者单点故障情况下，导致无法释放资源的问题；由于3pc的CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。参与者自身的超时机制会在超时后，自动进行本地commit，从而释放资源；这种机制也侧面降低了整个事务的阻塞时间和范围；
但是3pc依然无法解决数据不一致的问题;

3pc解决的问题	不能解决的问题
① 解决了协调者的单点故障，无法释放资源的问题：针对2pc的同步阻塞与单点故障问题，3pc对于协调者与参与者都设置了超时时间，而2pc只有协调者才拥有超时机制；`当进入第三阶段时，由于网络超时/网络分区等原因，如果第二阶段没有中断事务，虽然参与者没有收到commit或者abort响应，但是由于第二阶段的预提交所有参与者都回复了yes，他有理由相信：成功提交的几率很大；` ② 由于解决了单点故障问题，从侧面上也降低了整个事务的组设时间与范围；	① 3pc依然无法解决数据不一致问题：最后一个阶段，由于网络问题等，部分参与者收到了协调者发送的doCommit请求或者rollback请求，有一部分没有收到，就会导致数据不一致现象；

阶段	描述
`阶段一` 询问阶段 (CanCommit)	1）事务询问：协调者 (事务管理器) 向所有参与者发送包含事务内容的canCommit的请求，询问是否可以执行事务提交，并等待应答； 2）各参与者反馈事务询问：正常情况下，如果参与者认为可以顺利执行事务，则返回Yes，否则返回No； 3）各参与者向协调者反馈事务问询的响应：成功执行返回Yes，否则返回No；
`阶段二` PreCommit阶段 (执行阶段)	`1）执行事务预提交：若所有参与者 (资源管理器) 均回复yes，那么执行事务提交操作；` ① 发送预提交请求：协调者向所有节点发出PreCommit请求，并进入prepared阶段； ② 事务预提交：参与者收到PreCommit请求后，会开始事务操作，并将Undo和Redo日志写入本机事务日志； ③ 反馈结果：各参与者成功执行事务操作，同时将反馈以ACK响应形式发送给协调者，同时等待最终的Commit或Abort指令； `2）中断事务：若存在某一参与者向协调者发送No响应，或者等待超时；那么协调者就会中断事务；` ① 发送中断请求：协调者向所有参与者发送Abort请求； ② 中断事务：无论是参与者收到协调者的Abort请求，还是参与者等待协调者请求过程中出现超时，参与者都会中断事务；
`阶段三` doCommit阶段 (最终提交/回滚阶段)	`1）执行事务提交：协调者在上一阶段收到全部参与者回复的ACK消息；` ① 发送提交请求：若协调者收到了全部参与者的ACK响应，那么就从预提交状态转换为提交状态，并向全部的参与者发送doCommit请求； ② 事务提交：参与者收到doCommit请求后，会正式执行事务提交操作，并在完成提交操作后释放占用资源； ③ 反馈结果：参与者将在完成事务提交后，向协调者发送ACK消息； ④ 完成事务：协调者接收到所有参与者的Ack消息后，完成事务。 `2）回滚事务：协调者接收到任一个参与者发送的No响应，或在超时时间内，仍旧没收到反馈消息，就会回滚事务：` ① 发送中断请求：协调者向所有的参与者发送rollback请求； ② 事务回滚：参与者收到rollback请求后，会利用阶段二中的Undo消息执行事务回滚，并在完成回滚后释放占用资源； ③ 反馈结果：参与者在完成回滚后向协调者发送Ack消息； ④ 完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务回滚。

在这里插入图片描述

4、柔性事务：补偿型 + 通知型

柔性事务有两个特性：基本可用和柔性状态。

① 基本可用： 是指分布式系统出现故障的时候允许损失一部分的可用性。

② 柔性状态： 是指允许系统存在中间状态，这个中间状态不会影响系统整体的可用性，比如数据库读写分离的主从同步延迟等。柔性事务的一致性指的是最终一致性。

类型	描述
补偿型 `(同步)`	TCC（Try Confirm Commit）
通知型 `(异步)`	MQ事务消息、最大努力通知型

1）通知型事务

通知型	描述	实现
概念	通知型事务的主流实现是通过`MQ（消息队列）`来通知其他事务参与者自己事务的执行状态，引入MQ组件，有效的将事务参与者进行解耦，各参与者都可以异步执行，所以`通知型事务又被称为异步事务；`	MQ消息队列
适用场景	通知型事务主要适用于那些需要异步更新数据，并且对数据的实时性要求较低的场景	① 异步确保型事务：主要适用于`内部系统的数据最终一致性保障`，因为内部相对比较可控，如`订单和购物车`、`收货与清算`、`支付与结算`等等场景； ② 最大努力通知：主要用于外部系统，因为`外部的网络环境更加复杂和不可信`，所以只能尽最大努力去通知实现数据最终一致性，比如`充值平台与运营商`、`支付对接`等等`跨网络系统级别对接；`

在这里插入图片描述

① 异步确保型事务（MQ）

指将一系列同步的事务操作修改为基于消息队列异步执行的操作，来避免分布式事务中同步阻塞带来的数据操作性能的下降。

MQ事务消息方案

基于MQ的事务消息方案主要依靠MQ的 半消息机制 来实现 投递消息和参与者自身本地事务的一致性保障。半消息机制实现原理其实借鉴的2pc的思路，是二阶段提交的广义拓展。

半消息： 在原队列消息执行后的逻辑，如果后面的本地逻辑出错，则不发送该消息，如果通过则MQ发送；

MQ实现通知型事务流程

步骤	描述
1. 生产者→MQ	生产端首先发送半消息到MQ，MQ收到半消息后进行反馈，然后生产端开始执行本地事务；定时回查事务状态：如果在这个过程中生产端宕机或者超时，那么MQ服务器会循环的进行定时回查事务状态，确保MQ对这个半消息是需要提交给消费端还是直接丢弃；
2. MQ→消费者	生产者根据本地事务的执行结果，向MQ发送commit或者是rollback消息 ① 如果消息是rollback，那么MQ就丢弃消息不进行投递； ② 如果是commit，那么MQ就会将消息发送给消费者；
3. 消费者执行本地事务	消费者收到MQ的消息，执行本地事务；消息确保消费机制：消息消费成功与否主要是用MQ确保的 (比如消息确认机制、消息重试机制等)

在这里插入图片描述

② 最大努力通知

最大努力通知方案的目标，就是发起通知方通过一定的机制，最大努力将业务处理结果通知到接收方。
最大努力通知型的最终一致性： 本质是通过 引入定期校验机制 实现最终一致性，对业务的侵入性较低，适合于对最终一致性敏感度比较低、业务链路较短的场景。

MQ的ACK机制实现最大努力通知：

最大努力通知事务的特性
① 消息重复通知机制：消息发送方按照一定时间间隔的重复发送消息，直到接收消息的一方回复ACK；
② 消息校对机制：消息发送方要提供幂等性服务接口，提供给消息接收方进行查询，防止消息重复消费；

在这里插入图片描述

2）补偿型事务

TCC 分布式事务

模块	描述
Try 阶段	调用 Try 接口（自定义的prepare逻辑），尝试执行任务，完成所有业务检查，并锁定业务资源；此阶段可以通过两个CC阶段来提交或回滚；
Confirm阶段	对业务系统做确认提交，调用Confirm接口（自定义的commit逻辑），确认执行业务操作，不做业务检查，只使用Try阶段锁定的业务资源； TCC中添加了事务日志，如果此阶段操作失败，那么会根据事务日志进行重试，因此CC阶段需要 `支持幂等性`；如果重试失败，则需要人工介入进行恢复与处理；
Cancel阶段	当业务执行错误，调用Cancel接口（自定义的rollback逻辑），需要回滚已执行的业务取消，释放锁定资源；操作失败同样根据TCC事务日志进行重试处理；

在这里插入图片描述

TCC方案的异常问题解决方案：

问题	描述	解决方案
TCC空回滚问题	TCC阶段异常没有执行成功，但是Cancel阶段的回滚操作却执行了 (对数据进行了修改)，违反了一致性	解决问题的关键： `全局事务日志 + 分支事务日志`：识别出这个空回滚，即回滚前要知道Try是否执行； ① 全局事务贯穿整个分布式事务调用链，额外增加一张分支事务记录表，其中记录着全局事务ID与分支事务ID； ② 在第一阶段的Try阶段若正常执行，则分支事务表进行记录；当Cancel阶段执行时，首先`查询是否存在`该全局事务ID对应的Try记录 `(为了防止查询的时候没有Try记录，返回查询结果的时候又有Try记录了，此时可以用分布式锁)`，若有则正常回滚；否则不回滚；
TCC幂等问题	如果Confirm阶段或者Concel阶段返回执行失败结果（其实已经执行成功，但是响应回去的是失败），此时会根据是否日志进行重试，为了防止多次Confirm或者Concel，因此CC阶段必须支持幂等性；	具体解决方法： `全局事务日志 + 分支事务日志` 在分支事务日志中添加一个Confirm与Concel执行状态的字段，重试执行Confirm或者Concel时，先查一下是否执行过；没执行过了就执行，执行过了就不再执行；`(依然存在分布式问题，查询字段的时候没有执行，返回查询结果的时候有执行记录了，同样用分布式锁解决)`
TCC悬挂问题	分支事务Try阶段，由于网络发生拥堵，造成超时；此时达到超时时间后，分支事务执行Confirm或Concel，待到执行结束后，此时Try的网络阻塞解除，Try开始执行，那么此时预留资源就会卡住，无法进一步的再进行处理；	具体解决方法： `全局事务日志 + 分支事务日志` 在执行第一阶段Try时，首先查询分支事务日志是否有第二段记录，若有则不执行Try；

六、幂等性的解决方案（token机制）

查询操作与删除操作本身就具备幂等性，无需处理

token机制

对外提供的API如何保证幂等性 $api_token = md5 (模块名 + 控制器名 + 方法名 + 时间戳 + 加密密钥);

接口层面，保持接口访问的隐蔽性和有效性，保证接口只有可信任的来源才可以访问。

访问接口时，携带来源source标识与来源方seq序列号，这 两个字段在提供API访问接口的服务本地做联合索引；当第三方调用时，先在本系统中查询一下是否处理过；如果已处理，则返回响应的处理结果；如果没有处理过，则进行相应处理后再返回结果；

用户层面如何保证幂等性 $user_token = md5('用户的uid' + 'Unix时间戳' + '证书私钥')

① 数据提交前要向服务申请token，生成的token放到redis中，token设置有效时间；
② 每次提交时，携带者token，后台通过redis校验token (具体就是redis删除token)，若token删除成功，则验证成功；
③ 如果redis中不存在该token或者token删除失败，就证明已经有其它请求删除了token，则抛出请求重复信息；

token机制
对外提供的API如何保证幂等性	`$api_token = md5 (模块名 + 控制器名 + 方法名 + 时间戳 + 加密密钥);` 接口层面，保持接口访问的隐蔽性和有效性，保证接口只有可信任的来源才可以访问。访问接口时，携带来源source标识与来源方seq序列号，这 `两个字段在提供API访问接口的服务本地做联合索引`；当第三方调用时，先在本系统中查询一下是否处理过；如果已处理，则返回响应的处理结果；如果没有处理过，则进行相应处理后再返回结果；
用户层面如何保证幂等性	`$user_token = md5('用户的uid' + 'Unix时间戳' + '证书私钥')` ① 数据提交前要向服务申请token，生成的token放到redis中，token设置有效时间； ② 每次提交时，携带者token，`后台通过redis校验token (具体就是redis删除token)，若token删除成功，则验证成功；` ③ 如果redis中不存在该token或者token删除失败，就证明已经有其它请求删除了token，则抛出请求重复信息；