TCC分布式事务

**

TCC分布式事务

**
一.什么是分布式事务？
二.为什么会产生分布式事务？
三.常见的分布式事物有哪些？
四.TCC怎么解决分布式事务？
五.TCC分布式事务优缺？
六.TCC异常处理
七.公司系统举例
八.总结

一.什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

二.为什么会产生分布式事务

1.CAP定理
一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效)
可用性(Availability) ： 每个操作都必须以可预期的响应结束
分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成

2. BASE理论
   Basically Available（基本可用）
   Soft state（软状态）
   Eventually consistent（最终一致性）
   BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性

酸碱平衡：
ACID能够保证事务的强一致性，也就是数据的实时一致，这在本地事务中是没有问题的，在分布式事务中，强一致性会影响分布式系统的性能，因此分布式系统中要遵循Base理论，但是分布式系统在不同业务时对一致性要求也是不同的，就比如交易场景下，这个是需要强一致性的，再比如在发送短信验证码这个时候是可以不需要强一致性的，因此可以遵循Base即可，这就是所谓的酸碱平衡

三.常见的分布式事务2PC

1.两阶段提交（2PC）

一阶段：

作为事务协调者的节点会首先向所有的参与者节点发送Prepare请求。
在接到Prepare请求之后，每一个参与者节点会各自执行与事务有关的数据更新，写入Undo Log和Redo Log。如果参与者执行成功，暂时不提交事务，而是向事务协调节点返回“完成”消息

**二阶段：**如果事务协调节点在之前所收到都是正向返回，那么它将会向所有事务参与者发出Commit请求。
接到Commit请求之后，事务参与者节点会各自进行本地的事务提交，并释放锁资源。当本地事务完成提交后，将会向事务协调者返回“完成”消息。

优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）
缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

1.三阶段提交（3PC）

三阶段提交在两阶段提交的基础上增加了CanCommit阶段，并且引入了超时机制。一旦事物参与者迟迟没有接到协调者的commit请求，会自动进行本地commit。这样有效解决了协调者单点故障的问题。
优点： 相对于二级段提交协议，三阶段提交协议的最大的优点就是降低了参与者的阻塞的范围，并且能够在出现单点故障后继续达成一致
缺点： 三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是参与者接收到precommit消息后，如果出现网络分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务的提交，这必然出现数据的不一致性。

四.常见的分布式事务TCC

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。

它分为三个阶段：
Try 阶段主要是对业务系统做检测及资源预留
Confirm 阶段主要是对业务系统做确认提交，
Cancel 阶段是Try 执行失败对预留资源进行回滚操作

Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。
即：只要Try成功，Confirm一定成功
只要Try失败或者异常都会执行 Cancel

如果觉得TCC太高大上不理解，我们可以用本地事物ACID 进行对比，如图

从代码程序来说明，为了便于演示，将入参略去。原本的代码是这样的

运用TCC之后

3.补偿事务（Try-Confirm-Cancel）
正常情况：

五. TCC分布式事务优缺

优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些

缺点： 缺点还是比较明显的，在Confirm Cancel中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码。

**

六.TCC异常处理

**
幂等
问题：TC重复调用二阶段解决：事务状态控制记录作为控制手段，只有存在INIT记录时才执行，存在CONFIRMED/ROLLBACKED记录时不再执行

空回滚
问题：TC回滚事务调用二阶段，但一阶段尚未执行解决：事务状态控制记录作为控制手段，无记录时即为空回滚

资源悬挂
问题：TC回滚事务调用二阶段完成空回滚后，一阶段执行成功解决：事务状态控制记录作为控制手段，二阶段发现无记录时插入记录，一阶段执行时检查记录是否存在

共通点
核心的解决方案就是事务状态控制表
幂等控制作为最基础的异常处理手段；资源悬挂的前置条件是空回滚，所以发生空回滚时会插入一条状态为ROLLBACKED的控制记录

结语：
分布式事务分享到这里就要和各位小伙伴们说再见了。在分享前的准备过程中，我和我的小伙伴们工作之余，分工合作，查找资料，在此过程中学习、总结，然后给大家呈现出来，与大家共同进步。
在此过程中我们遇到了如何把TCC融入到PHP框架中，TCC在confirm、cancel阶段如果遇到异常情况的处理机制，各位小伙伴们，关于这些情况，如果你们遇到了，会有什么好的解决措施呢？
在公司现有系统如OMS、MP、RP、AGENT、TMS等相互交互时，一个系统功能中同时使用了多个系统，若多个系统同步成功，一个系统同步失败，这种情况像前面所讲的TCC处理异常那样吗？