分布式事务之LCN、TCC特点、事务补偿机制缘由以及设计重点

2401_84049088

于 2024-04-19 22:43:28 发布

阅读量819

点赞数 23

分类专栏：程序员文章标签：分布式

本文链接：https://blog.csdn.net/2401_84049088/article/details/137979750

版权

程序员专栏收录该内容

434 篇文章 0 订阅

订阅专栏

文章介绍了分布式事务协调机制，包括二阶段提交协议的流程，如协调者询盘、事务提交决策，以及LCN框架如何作为协调者进行事务管理。同时，TCC机制通过业务逻辑调度实现分布式事务，强调Try、Confirm和Cancel阶段的特点及业务补偿的重要性。

摘要由CSDN通过智能技术生成

协调者向所有的参与者发送事务执行请求，并等待参与者反馈事务执行结果；
事务参与者收到请求之后，执行事务但不提交，并记录事务日志；
参与者将自己事务执行情况反馈给协调者，同时阻塞等待协调者的后续指令。

第二阶段：事务提交

=========

在经过第一阶段协调者的询盘之后，各个参与者会回复自己事务的执行情况，这时候存在 3 种可能性：

所有的参与者都回复能够正常执行事务。
一个或多个参与者回复事务执行失败。
协调者等待超时。

对于第 1 种情况，协调者将向所有的参与者发出提交事务的通知，具体步骤如下：

协调者向各个参与者发送 commit 通知，请求提交事务；
参与者收到事务提交通知之后执行 commit 操作，然后释放占有的资源；
参与者向协调者返回事务 commit 结果信息。

除此之外, 还有2种情况, 囿于篇幅, 详情参考: 亿级流量架构之分布式事务思路及方法后面的二阶段提交协议

今天要聊的TCC就是二阶段提交的具体事务实现。

LCN

===

详情参考:官网(中文版)

有了前面的XA协议以及二阶段提交的知识, 就不难理解LCN框架了, 这个框架可以理解成就是上面所说的协调者, 不生产事务, 只负责协调事务。5.0以后框架兼容了LCN、TCC、TXC三种事务模式。

LCN中各个字母依次代表:锁定事务单元（lock）、确认事务模块状态(confirm)、通知事务(notify)。

在一个分布式系统下存在多个模块协调来完成一次业务。那么就存在一次业务事务下可能横跨多种数据源节点的可能。TX-LCN目的是解决这样的问题。

例如存在服务模块A 、B、 C。A模块是mysql作为数据源的服务，B模块是基于redis作为数据源的服务，C模块是基于mongo作为数据源的服务。若需要解决他们的事务一致性就需要针对不同的节点采用不同的方案，并且统一协调完成分布式事务的处理。

在LCN中, 协调者称之为TxManager , 参与者称之为 TxClient, TxManager作为分布式事务的控制方, 事务发起方或者参与方都由TxClient端来控制决定。

时序图(来源官网):

LCN核心步骤

=======

创建事务组

是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。

加入事务组

添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。

通知事务组

是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。

TCC

===

详情参考: Github(中文版)

TCC事务机制相对于二阶段提交，其特征在于它不依赖资源管理器(RM)对XA协议的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务, 将事务分成 Try 和 Confirm/ Cancel两个阶段。

三种操作作用: Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。

整体流程如图

Try 从执行阶段来看，与传统事务机制(二阶段提交)中业务逻辑相同。但从业务角度来看，却不一样。TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑。TCC机制将传统事务机制(2PC)中的业务逻辑一分为二:

拆分后保留的部分为初步操作（Try）；

而分离出的部分即为验证操作（Confirm/cancel），被延迟到事务提交阶段执行。

三阶段主要特点:

	Try 阶段	Confirm阶段	Cancel阶段
主要含义	尝试执行业务	确认执行业务	取消执行业务
执行操作	完成所有业务检查( 一致性 )	不做任务业务检查	释放 Try 阶段预留的业务资源
	预留必需业务资源( 准隔离性 )	Confirm 操作满足幂等性	Cancel 操作满足幂等性
		真正执行业务

TCC补偿机制

=======

在很多情况下，我们是无法做到强一致的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。比如，在我们的日常生活中，我们经常会遇到这样的情况，就是要找很多方协调很多事，而且要保证我们每一件事都成功，否则整件事就做不到。

比如，要出门旅游，我们需要干这么几件事。

第一，向公司请假，拿到相应的假期；

第二，订飞机票或是火车票；

第三，订酒店；

第四，租车。

这四件事中，前三件必须完全成功，我们才能出行，而第四件事只是一个锦上添花的事，但第四件事一旦确定，那么也会成为整个事务的一部分。这些事都是要向不同的组织或系统请求。我们可以并行地做这些事，而如果某个事有变化，其它的事都会跟着出现一些变化。

设想下面的几种情况。

我没有订到返程机票，那么我就去不了了。我需要把订到的去程机票，酒店、租到的车都给取消了，并且把请的假也取消了。
如果我假也请好了，机票，酒店也订好了，只是车没租到，那么并不影响我出行这个事，整个事还是可以继续的。
如果我的飞机因为天气原因取消或是晚点了，那么我被迫要去调整和修改我的酒店预订和租车的预订。

从人类的实际生活当中，我们可以看出，上述的这些情况都是天天在发生的事情。所以，我们的分布式系统也是一样的，也是需要处理这样的事情——就是当条件不满足，或是有变化的时候，需要从业务上做相应的整体事务的补偿。

对于业务补偿来说，首先需要将服务做成幂等性的，如果一个事务失败了或是超时了，我们需要不断地重试，努力地达到最终我们想要的状态。然后，如果我们不能达到这个我们想要的状态，我们需要把整个状态恢复到之前的状态。另外，如果有变化的请求，我们需要启动整个事务的业务更新机制。

业务补偿机制特点

========
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

既已说到spring cloud alibaba，那对于整个微服务架构，如果想要进一步地向上提升自己，到底应该掌握哪些核心技能呢？

就个人而言，对于整个微服务架构，像RPC、Dubbo、Spring Boot、Spring Cloud Alibaba、Docker、kubernetes、Spring Cloud Netflix、Service Mesh等这些都是最最核心的知识，架构师必经之路！下图，是自绘的微服务架构路线体系大纲，如果有还不知道自己该掌握些啥技术的朋友，可根据小编手绘的大纲进行一个参考。