在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于CAP理论以及BASE理论，有人就提出了柔性事务的概念。在业内，关于柔性事务，最主要的有以下四种类型：两阶段型、补偿型、异步确保型、最大努力通知型几种。我们前边讲过的2PC和3PC都属于两阶段型，两阶段型事务存在长期锁定资源的情况，导致可用性差。接下来我们来介绍的TCC则是补偿型分布式事务。
TCC（Try-Confirm-Cancel）分布式事务的核心思想是通过将一个复杂的分布式事务分解为三个阶段：尝试（Try）、确认（Confirm）和取消（Cancel），来实现分布式系统中的事务一致性。
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系统中的分布事务处理》中。
在分布式系统中，事务的一致性、原子性和隔离性是一个巨大的挑战。为了解决这个问题，许多分布式事务解决方案应运而生。在前面我们也讲解了使用XA协议，但是XA需要数据库层面支持，数据库控制事务，而且XA协议也很少使用了，所以本文将继续讲解分布式事务的另一种解决方案TCC协议。TCC（Try-Confirm-Cancel）协议是一种广泛使用的分布式事务处理方案。本文将详细介绍TCC协议的设计思想、实现原理和优缺点。
在实现TCC（Try-Confirm-Cancel）时，分布式事务日志的持久化和恢复是非常重要的，它可以帮助我们在分布式系统中实现可靠的事务处理。下面是一种常见的方法来处理分布式事务日志的持久化和恢复。
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系统中的分布事务处理》中。
TCC（Try-Confirm-Cancel）是一种分布式事务管理模式，在正常情况下，TCC的每个操作都会按照顺序执行，并在每个操作执行完成后确认。但是，当遇到异常情况时，TCC中的"尝试"操作会进行异常处理。
关于TCC的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
步骤四出险异常，1自动回滚，3的操作不会回滚，导致双方数据不同步。不符合同时成功、同时失败原则。
在TCC（Try-Confirm-Cancel）中，存在死锁的风险，但不存在活锁的风险。
事情还得从事务说起。我说事情总是喜欢从字面意义说起。那事务究竟是什么意思呢？得从它的英文说起：Transaction。
在上篇文章《老生常谈——利用消息队列处理分布式事务》一文中留了一个坑，今天来填坑。如下图所示
TCC方案是可能是目前最火的一种柔性事务方案了。关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。在该论文中，TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司，其注册了TCC商标。
前面我们讲了分布式事务的基本概念，CAP理论等，也讲了2pc协议，3pc协议，我们可以暂时认为2pc协议，3pc协议他们是传统的事务处理机制，这一篇，我们讲一讲TCC（Try-Confirm-Cancel） 事务机制，相对于传统事务机制（X/Open XA Two-Phase-Commit），TCC的特别之处在于它不依赖资源管理器(RM)对XA的支持，而是通过对业务逻辑（由业务系统提供的）的调度来实现分布式事务。
https://juejin.im/post/5b5a0bf9f265da0f6523913b
在分布式系统设计中，随着微服务的流行，通常一个业务操作被拆分为多个子任务，比如电商系统的下单和支付操作，就涉及到了创建和更新订单、扣减账户余额、扣减库存、发送物流消息等，那么在复杂业务开发中，如何保证最终数据一致性呢？
接触分布式相关的开发已经有一段时间了，自然绕不开分布式事务。从本文开始，我将带领大家了解常见的分布式事务的解决方案，深入原理，浅出实践，让我们在今后的开发中对分布式事务不再畏惧。
假设现在有一个电商系统，里面有一个支付订单的场景，那对一个订单支付之后，我们需要做下面的步骤
在终一致性分布式事务解决方案中，服务模式是指协调分布式事务时涉及的角色和交互方式。
什么是分布式事务 问题的引出 先看一张图，一个电商平台的架构图。 对于用户来说的一个创建订单的过程，背后很可能跨越了多个应用服务。涉及诸如：订单、库存、积分、优惠券等多个微服务模块，而每个模块的数
参与者将本身事务的执行情况发送给事务协调者，由事务协调者判断事务调用链是否执行提交操作还是回滚操作
一致性分为强一致性和弱一致性。 强一致性的协议和手段主要有：二阶段提交(2PC)、三阶段提交(3PC)、TCC(Try-Confirm-Cancel)补偿型。这里面经常有人把两阶段提交和TCC补偿型混淆。二阶段提交实际上业务逻辑是在提交之前做的，两阶段只是事务控制的两个阶段。而TCC是将业务逻辑分为try、confirm和cancel三个阶段。举个例子：比如一个人要预售苹果，有两种销售策略。一种让用户先付钱，根据用户需求量准备足够的苹果。另一种是让用户先付钱同时声明到时候先到先得，没抢到的就退款。第一种就是二阶段提交，第二种就是TCC。弱一致性在分布式系统中常用的是一种特例：最终一致性。在工作中，最终一致性通常通过补单和对账来解决。补单主要指在运行时同时检查返回值，如果返回值为失败，会重新处理（补单处理）。 对账主要分为两个阶段：数据核对和差错处理。数据核对就是对账中的轧账。注意「轧」这里念「ga」二声。差错处理就是对账中的平账。
TCC（Try-Confirm-Cancel）是一种分布式事务处理模式，它包含以下几个关键技术：
Seata通过引入**全局事务**的概念，将一个分布式事务分解为多个局部的分支事务，这些分支事务分布在不同的服务或者数据库中。为了协调这些分支事务，Seata定义了三个关键组件：
大家好，今天我给大家分享的题目是微服务架构下的数据一致性保证。 今天分享第一篇，主要内容包括： 1.传统使用本地事务和分布式事务保证一致性。 2.传统分布式事务不是微服务中一致性的最佳选择。 3.微
这就是分布式事物问题,当APP要买东西,这个操作会涉及到多个服务,意味着要操作多个数据库,这样本地事物就无法保证数据的一致性,所以就产生了分布式事物问题.
互联网的世界与十几年前相比，已经大不相同。以往的单体服务就可以支撑起大多数的用户需求。然而随着手机等电子产品的普及，用户想要的服务已经是越来越复杂，各种需求相互关联。而这也给软件开发带来了更多的挑战。为了应付随时会变化的代码世界，现有的开发趋势都在逐渐的化整为零。其中最具代表性的就是微服务的流行。
XA 是由 X/Open 组织提出的分布式事务规范，XA 规范主要定义了事务协调者（Transaction Manager）和资源管理器（Resource Manager）之间的接口。
数据库事务（简称：事务），是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。
引言 在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的。而在金融领域，一致性是最为关注的特性，任何情况下都必须满足一致性。关于CAP定律和BASE理论，本文不再介绍，有兴趣的同学可以自行百度一下。本文重点来阐述下关于一致性的方案，包括强一致性和最终一致性。 而在互联网领域， 很多情况下都是牺牲强一致性，来达到高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用
针对分布式系统的特点，基于不同的一致性需求产生了不同的分布式事务解决方案，追求强一致的两阶段提交、追求最终一致性的柔性事务和事务消息等等。各种方案没有绝对的好坏，抛开具体场景我们无法评价，更无法能做出合理选择。在选择分布式事务方案时，需要我们充分了解各种解决方案的原理和设计初衷，再结合实际的业务场景，从而做出科学合理的选择。
几乎所有的信息管理系统都会涉及到事务，事务的目的是为了保证数据的一致性，这里说的一致性是数据库状态的一致性。
从2014年开始，微服务逐渐进入大家的实现，被认为是下一代实现信息化的有效手段。设计到系统，其中绕不开的就是数据一致性，从本地事务，到后来的分布式事务，都能够有效的保证数据一致性。但是在微服务架构中，这两种方式都不是最好的选择。
提起微服务架构，不可避免的两个话题就是服务治理和分布式事务。数据库和业务模块的垂直拆分为我们带来了系统性能、稳定性和开发效率的提升的同时也引入了一些更复杂的问题，例如在数据一致性问题上，我们不再能够依赖数据库的本地事务，对于一系列的跨库写入操作，如何保证其原子性，是微服务架构下不得不面对的问题。
分布式事务解决方案几乎都是柔性事务，常见的有2PC/3PC、TCC、MQ最终一致性解决方案，至于工作中用哪种方案，需要根据业务场景选取，2PC/3PC、TCC数据强一致性高，而MQ是最终数据一致。
本文我们聊聊分布式事务和事务型消息的解决思路，通过阅读本文，可以理解分布式事务和事务型消息，并且能够应用到实际生产工作中。
随着业务的快速发展、业务复杂度越来越高，几乎每个公司的系统都会从单体走向分布式，特别是转向微服务架构。随之而来就必然遇到分布式事务这个难题，这篇文章总结了分布式事务最经典的解决方案，分享给大家。
随着业务的快速发展、业务复杂度越来越高，几乎每个公司的系统都会从单体走向分布式，特别是转向微服务架构。随之而来就必然遇到分布式事务这个难题。
前两天有个学弟公众号留言，说让讲讲分布式事务，面试就挂在这个问题上。时下随着微服务架构体系的流行，面试的题目也都慢慢开始升级，不再是早些年单纯的问点SSH框架知识、数据结构了。高并发、高可用、分布式服务治理、分布式文件系统、分布式xxx，反正和分布式沾边的都会问点， 项目实际用不用不要紧，关键你得了解，是不是总有一种学不动了的感觉？
因为最近项目正在做重构，而这次重构实质上比原来更接近于SOA化和微服务的思想。对于我们金融交易来说，数据结果的准确性是重中之重。所以今天总结一下分布式事务的实现方法，下次组内周会给大家统一一下概念。 刚性事务和柔性事务 刚性事务：严格遵循ACID原则（原子性、一致性、隔离性、持久性）的事务。基本上指的是本地数据库事务。根据CAP原则，分布式下的事务都不是刚性事务。 柔性事务：遵循CAP理论或者其变种BASE理论的事务。分布式事务基本上都是柔性事务。 因为刚性事务基本上等价于本地数据库事务，而
Seata 目前支持 AT 模式、XA 模式、TCC 模式和 SAGA 模式，之前文章更多谈及的是非侵入式的 AT 模式，今天带大家认识一下同样是二阶段提交的 TCC 模式。
随着微服务架构的推广，越来越多的公司采用微服务架构来构建自己的业务平台。就像前边的文章说的，微服务架构为业务开发带来了诸多好处的同时，例如单一职责、独立开发部署、功能复用和系统容错等等，也带来一些问题。
上一篇文章我们将整个交易系统进行了微服务化，拆分为了多个相互独立的业务组件，每个业务组件不只是包含自己业务的微服务，还包括了独立管理的数据库。那么，我们来考虑下单的场景，用户下委托单的时候，主要有三步操作：一是冻结金额，二是新增订单，三是投递给到撮合引擎。这三步需要保证事务的一致性。在服务和数据库都不拆分的情况下，是很容易满足的。但拆分之后，这几个步骤的操作也分开到不同业务组件了，服务是分开的，数据库也是分开的。在这种分布式的环境下，又要如何保证事务的一致性，这就是分布式事务问题了。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
