上一次我们讲解了分布式事务的 2PC、3PC 。那么这次我们来理一下 TCC 事务。本次还是讲解 TCC 的原理跟 .NET 其实没有关系。
TCC概念由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出, 在该论文中，TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司，并且还注册了TCC商标。国内最早可查引进TCC概念，应是阿里程立2008年在 软件开发2.0大会 上分享主题《大规模SOA系统中的分布事务处理》中。
在前一篇文章中讲到了BASE模式，这种模式可以应用在单库or跨库事务的场景下。事实上BASE模式不仅仅局限于数据库层面，还可以应用于分布式系统，这类分布式系统最典型的例子就是电商平台，它们有以下几个特征：
在微服务架构盛行的情况下，在分布式的多个服务中保证业务的一致性，即分布式事务就显得尤为重要。本文将讲述分布式事务及其解决方案，有XA协议、TCC和Saga事务模型、本地消息表、事务消息和阿里开源的Seata。
TCC概念由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出, 在该论文中，TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司，并且还注册了TCC商标。国内最早可查引进TCC概念，应是阿里程立2008年在 软件开发2.0大会 上分享主题《大规模SOA系统中的分布事务处理》中。
前两天有个学弟公众号留言，说让讲讲分布式事务，面试就挂在这个问题上。时下随着微服务架构体系的流行，面试的题目也都慢慢开始升级，不再是早些年单纯的问点SSH框架知识、数据结构了。高并发、高可用、分布式服务治理、分布式文件系统、分布式xxx，反正和分布式沾边的都会问点， 项目实际用不用不要紧，关键你得了解，是不是总有一种学不动了的感觉？
在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于CAP理论以及BASE理论，有人就提出了柔性事务的概念。在业内，关于柔性事务，最主要的有以下四种类型：两阶段型、补偿型、异步确保型、最大努力通知型几种。我们前边讲过的2PC和3PC都属于两阶段型，两阶段型事务存在长期锁定资源的情况，导致可用性差。接下来我们来介绍的TCC则是补偿型分布式事务。
分布式事务解决方案几乎都是柔性事务，常见的有2PC/3PC、TCC、MQ最终一致性解决方案，至于工作中用哪种方案，需要根据业务场景选取，2PC/3PC、TCC数据强一致性高，而MQ是最终数据一致。
前面我们说了两期分布式事务模型，分别是2PC和3PC，2PC模型它的效率比较低，并且会出现事务阻塞等问题，所以引入了3PC模型， 3PC模型在2PC模型的基础上进行了改进，避免了事务阻塞问题，不过对于2PC和3PC模型，他们依然是阻塞的，也就是说当前事务在 执行的过程中，其他事务都会被阻塞，所以实际上他们的效率都不高，如果对于并发量不发的系统，那么可以选择它们，但是在高并发的 场景下，用2PC模型和3PC模型，显然就不行了，所以今天我们引入了TCC模型。
在分布式系统设计中，随着微服务的流行，通常一个业务操作被拆分为多个子任务，比如电商系统的下单和支付操作，就涉及到了创建和更新订单、扣减账户余额、扣减库存、发送物流消息等，那么在复杂业务开发中，如何保证最终数据一致性呢？
对于分布式事务，相信所有人都应该很了解，为什么会有分布式事务？无论是数据量导致的分库，还是现在微服务盛行的场景都是他出现的原因。
还记得刚入行开始写Java时，接触的第一个项目是国家电网的一个业务系统，这个系统据说投资了5亿人民币进行研发，鼎盛时期研发人员一度达到过500人。项目采用当时最流行的ssh（Struts+Spring+Hibernate）框架，典型的三层架构（controller - > service -> dao）简单又粗暴，所有人写的代码都放在一个大工程里，项目文件大小达到几百M，解决代码冲突是当时最大的工作量。
上一篇文章已经讲完分布式了，那暖男说要讲分布式事务那就一定会讲，只是我估计大家没料到暖男这么快就肝好了吧？
事务是数据库从一个稳定状态变迁到另一个稳定状态的保证，具备 ACID 这 4 个特性：
TCC是支付宝提出的分布式事务解决方案，是 try、confirm、cancel 的缩写。
本文补充一种分布式事务解决方法：Best Effort. Best Effort best effort即尽最大努力交付，主要用于在这样一种场景：不同的服务平台之间的事务性保证。比如我们在电商购物，使用支付宝支付；又比如玩网游的时候，通过App Store充值。拿购物为例，电商平台与支付平台是相互独立的，隶属于不同的公司，即使是同一个公司也很可能是独立的部门。因此，这两个平台是不可能使用同一套分布式事务框架的，2PC不行，tcc也不行，异步消息也不行。 其实在上面电商平台与支付平台的例子中，涉及到
Innodb采用MVCC多版本并发控制实现读写并发执行，并且以此来支持读已提交和可重复读两个隔离级别，核心在于快照创建时间点不同，前者是每次select时创建快照版本，后者是在事务开始时创建快照版本。
我们了解到了分布式事务的基础概念。与本地事务不同的是，分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同机器上，相互之间通过网络交互。不能因为有一点网络问题就导致整个系统无法提供服务，网络因素成为了分布式事务的考量标准之一。因此，分布式事务需要更进一步的理论支持，接下来，我们先来学习一下分布式事务的CAP理论。
单体数据库不涉及网络交互，所以在多表之间实现事务是比较简单的，这种事务称之为本地事务。
上一篇文章我们将整个交易系统进行了微服务化，拆分为了多个相互独立的业务组件，每个业务组件不只是包含自己业务的微服务，还包括了独立管理的数据库。那么，我们来考虑下单的场景，用户下委托单的时候，主要有三步操作：一是冻结金额，二是新增订单，三是投递给到撮合引擎。这三步需要保证事务的一致性。在服务和数据库都不拆分的情况下，是很容易满足的。但拆分之后，这几个步骤的操作也分开到不同业务组件了，服务是分开的，数据库也是分开的。在这种分布式的环境下，又要如何保证事务的一致性，这就是分布式事务问题了。
TCC（Try-Confirm-Cancel）是一种分布式事务处理模式，它包含以下几个关键技术：
在上一篇文章《【分布式事务】基于RocketMQ搭建生产级消息集群？》中给大家介绍了基于RocketMQ如何搭建生产级消息集群。因为本系列文章最终的目的是介绍基于RocketMQ的事物消息来解决分布式系统中的数据一致性问题，所以先给大家率先介绍了RocketMQ消息集群的搭建。
刚性事务：顾名思义，非常的“刚”，属于硬刚的那种。这个分布式事务要么全成功，要么全回滚，别跟我提什么中间状态，我的人生中不允许出现模棱两可。其中包括：XA、2PC、3PC
我们已经了解了四种分布式事务解决方案，2PC【链接】、TCC【链接】、可靠消息最终一致性【链接】、最大努力通知【链接】，每种解决方案我们通过案例开发进行学习，本章节我们结合互联网金融项目中的业务场景，来进行分布式事务解决方案可行性分析。
在微服务架构中，随着服务的逐步拆分，数据库私有已经成为共识，这也导致所面临的分布式事务问题成为微服务落地过程中一个非常难以逾越的障碍，但是目前尚没有一个完整通用的解决方案。
完成某件事情，可能有多个参与者需要执行多个步骤，最终多个步骤要么全部成功，要么全部失败。
在TCC（Try-Confirm-Cancel）中，存在死锁的风险，但不存在活锁的风险。
分布式事务的基本概念与本地事务类似，都保证了 ACID 特性（见[本篇第二章](# 二. 事务的特性)）。随着数据的规模越来越大，就出现了对业务的解构，包括数据层面的关系型数据库的垂直、水平分表，以及服务层面的拆分，将一个大服务拆分为后单独部署，甚至同时也将数据库独立出来。这时候本地数据库事务就不能满足多个数据库、异构系统的原子性、持久性了，需要使用分布式事务的方法。通常，分布式事务只需要保证原子性，通过保证原子性来保证应用层面的一致性，由本地事务保证隔离性和持久性。 从 CAP 特性上考虑，由于分布式事务存在网络分割的情况，所以一定需要满足分区容忍性，剩下的需要在一致性 (Consistency) 与可用性 (Available) 之间做权衡。下面提到各种分布式事务的实现方法与协议，都是需要在一致性与可用性之间权衡的。
XA 是由 X/Open 组织提出的分布式事务规范，XA 规范主要定义了事务协调者（Transaction Manager）和资源管理器（Resource Manager）之间的接口。
参与者将本身事务的执行情况发送给事务协调者，由事务协调者判断事务调用链是否执行提交操作还是回滚操作
这次使用分布式事务框架过程中了学习了一些分布式事务知识，所以本文我们就来聊聊分布式事务那些事。首先我们先回顾下什么是事务。
两阶段提交就是使用XA协议的原理，我们可以从下面这个图的流程来很容易的看出中间的一些比如commit和abort的细节。
补偿事务（TCC） 针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：
数据库里的事务大家都不陌生，而在微服务架构中由于一个任务执行可能涉及多个微服务，要想在分布式系统实现事务 就要用到分布式事务了。
事务提供一种机制将活动中涉及所有操作纳入到一个不可分割的执行单元。整个单独单元作为一个不可分割的整体，如果单元中某条sql语句一旦执行失败或者产生错误，整个单元将会回滚，也就是所有受到影响的数据将会返回到事务开始以前的状态；如果单元中的所有sql语句均执行成功，则事务被顺利执行。
事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。
前面几篇《打开我的收藏夹》文都让我受益匪浅，在此我还是想说一句：都是自己当初收藏的，就不要吃灰了，逐渐放空掉自己的收藏夹未必不是一件好事。
事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。
2PC 最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定，此时服务会阻塞并锁定资源。由于其阻塞机制和最差时间复杂度高， 因此，这种设计不能适应随着事务涉及的服务数量增加而扩展的需要，很难用于并发较高以及子事务生命周期较长 (long-running transactions) 的分布式服务中。
分布式事务学习项目：流量充值中心 git地址：https://github.com/barrywangmeng/data-refill-center
TCC之外另一个常见的终一致性分布式事务解决方案是基于两阶段提交（Two-Phase Commit，2PC）协议。
今天小编带来的是分享课题是分布式事务。小编是在一家O2O公司做程序员，今天就以公司的一则订单业务来作为分享课题的场景。
事务（Transaction）是并发控制的单位，是用户定义的一个操作序列。 这些操作要么都做，要么都不做，是一个不可分割的工作单位。
这两天正在研究微服务架构中分布式事务的处理方案, 做一个小小的总结, 作为备忘. 如有错误, 欢迎指正!
分布式一致性是一个常见的问题，比如在本地表中插入了一条记录，同时又远程调用了一个服务，很有可能插入记录成功了，但远程调用超时了，亦或本地记录插入成功了，此时刚好机器重启了......我们遇到的实际问题远非这个例子，根据自己的经验，在业务初期，很少关注这种一致性问题，有两方面的问题：一是这种发生的概率较小，就没有花时间去解决；二是业务在快速跑，容忍了这种异常场景存在。在本篇文章中会全方面位分析分布式一致性的问题、业内标准解决方案、实际工作解决方法
两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。
什么是分布式事务?此时我我们需要了解一下什么是本地事务；说到本地事务此时我们就需要谈一下什么是事务以及以下几种概念。 事务: 百度百科是这样说的事务（Transaction） 一般是指要做的或所做的事
C：一致性被称为原子对象，任何的读写都应该看起来是“原子”，或串行的。写后面的读一定能读到前面写的内容，所有的读写请求都好像被全局排序。 A：对任何非失败节点都应该在有限时间内给出请求的回应。（请求的可终止性） P：允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失
事务（Transaction）：一般是指要做的或所做的事情，由 事务开始(begin transaction) 和 事务结束(end transaction) 之间执行的全体操作组成。
2pc实现：https://github.com/codingapi/tx-lcn
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
