tcc

分布式事务TCC两阶段提交 两阶段提交 在提交事务的过程中需要在多个节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时，比较耗时，锁资源发生冲突的概率增加，当事务的并发量达到一定数量的时候，就会出现大量事务积压甚至出现死锁，系统性能就会严重下滑。 TCC型事务 TCC属于补偿型柔性事务，本质也是一个两阶段型事务。 TCC（Try-Confirm-Cancel） TCC分三部分，如下所述： Try: 尝试执行业务； Confirm: 确认执行业务； Cancel: 取消执行业务； 实例 Try 操作 tryX 下单系统创建待支付订单 tryY 冻结账户红包200元 tryZ 冻结资金账户800元 Confirm 操作 confirmX 订单更新为支付成功 confirmY 扣减账户红包200元 confirmZ 扣减资金账户800元 Cancel 操作 cancelX 订单处理异常，资金红包退回，订单支付失败 cancelY 冻结红包失败，账户余额退回，订单支付失败 cancelZ 冻结余额失败，账户红包退回，订单支付失败 来源： oschina 链接： https://my.oschina.net/wallenheng/blog/3190895

深入了解分布式 分布式事务 分布式事务概念 分布式事务产生的原因 事务的ACID特性 分布式理论 CAP理论 BASE理论 分布式事务的应用场景 常见的分布式事务解决方案 两阶段提交 TCC编程模式 TCC开源框架-tcc-transaction TCC使用关键技术分析 分布式项目使用tcc-transaction框架 发布服务 调用服务 LCN解决方案 参考链接 分布式事务 分布式事务概念 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 分布式事务是为了保证不同数据库的数据一致性 分布式事务产生的原因 数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表 应用SOA化 所谓的SOA化，就是业务的服务化。现在对整个网站进行拆解，分离除了订单中心、用户中心、库存中心。 事务的ACID特性 原子性(Atomicity) 所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。 一致性(Consistency) 事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了

转载自： 如何选择分布式事务形态（TCC，SAGA，2PC，补偿，基于消息最终一致性等等） 各种形态的分布式事务 分布式事务有多种主流形态，包括： 基于消息实现的分布式事务 基于补偿实现的分布式事务(gts/fescar自动补偿的形式) 基于TCC实现的分布式事务 基于SAGA实现的分布式事务 基于2PC实现的分布式事务 之所以有这么多形态，是 因为任何事情都没有银弹，只有最合适当前场景的解决方案 。 这些形态的原理已经在很多文章中进行了剖析，用“分布式事务”关键字就能搜到对应的文章，本文不再赘述这些形态的原理，并将重点放在如何根据业务选择对应的分布式事务形态上。 何时选择单机事务？ 这个相信大家都很清楚，在条件允许的情况下，我们应该尽可能地使用单机事务，因为单机事务里，无需额外协调其他数据源，减少了网络交互时间消耗以及协调时所需的存储IO消耗，在修改等量业务数据的情况下，单机事务将会有更高的性能。 但单机数据库由于 业务逻辑解耦等因素进行了数据库垂直拆分、或者由于单机数据库性能压力等因素进行了数据库水平拆分之后，数据分布于多个数据库，这时若需要对多个数据库的数据进行协调变更，则需要引入分布式事务。 分布式事务的模式有很多种，那究竟要怎么选择适合业务的模式呢？以下我们将从使用场景、性能、开发成本这几个方面进行分析。 何时选择基于消息实现的事务？

各种形态的分布式事务 分布式事务有多种主流形态，包括： 基于消息实现的分布式事务 基于补偿实现的分布式事务 基于TCC实现的分布式事务 基于SAGA实现的分布式事务 基于2PC实现的分布式事务 这些形态的原理已经在很多文章中进行了剖析，用“分布式事务”关键字就能搜到对应的文章，本文不再赘述这些形态的原理，并将重点放在如何根据业务选择对应的分布式事务形态上。 何时选择单机事务？ 这个相信大家都很清楚，在条件允许的情况下，我们应该尽可能地使用单机事务，因为单机事务里，无需额外协调其他数据源，减少了网络交互时间消耗以及协调时所需的存储IO消耗，在修改等量业务数据的情况下，单机事务将会有更高的性能。 但单机数据库由于 业务逻辑解耦等因素进行了数据库垂直拆分、或者由于单机数据库性能压力等因素进行了数据库水平拆分之后，数据分布于多个数据库，这时若需要对多个数据库的数据进行协调变更，则需要引入分布式事务。 分布式事务的模式有很多种，那究竟要怎么选择适合业务的模式呢？以下我们将从使用场景、性能、开发成本这几个方面进行分析。 何时选择基于消息实现的事务？ 基于消息实现的事务适用于分布式事务的提交或回滚只取决于事务发起方的业务需求，其他数据源的数据变更跟随发起方进行的业务场景。 举个例子，假设存在业务规则：某笔订单成功后，为用户加一定的积分。 在这条规则里，管理订单数据源的服务为事务发起方

1.什么是TCC TCC 是 Try 、 Confirm 、 Cancel 三个词语的缩写，TCC要求每个分支事务实现三个操作 ： 预处理Try 、 确认Confirm 、 撤销Cancel 。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作既回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败， TM 会进行重试。 分支事务失败的情况 ： TCC分为三个阶段 ： Try阶段是做业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的Confirm一起才能真正构成一个完整的业务逻辑。 Confirm阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行Confirm。通常情况下，采用TCC则认为Confirm阶段是不会出错的。即 ：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。 Cancel阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务 一、业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 二、进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。 结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！ 但是如果你不用 TCC 分布式事务方案的话，就用个 Spring

TCC和XA的区别和概述 TCC 主要限制 对业务有侵入性，需要提供了三个接口。 主业务服务和从业务服务都需要进行改造，从业务方改造成本更高。如果从业务方还不是自己的公司的话那更是成本提高了（可能人家都不搭理你），原来只需要提供一个接口，现在需要改造成try、confirm、canel3个接口，开发成本高。 使用范围（业务层面的控制） 分布式架构，TCC是分布式事务，是最终一致性的，不会长期持有所有数据库资源的锁，原理上还是提交本地事务，所以不会存在长事务，这样就和本地事事务没有区别，性能很好。 第一阶段由发起方（发起所在的程序）发出try请求，第二阶段由事务管理器发起confirm／cancel请求，而且采用了异步实现。 概述和原理 原来一个接口就可以，现在要提供三个接口 try 数据就生效了，提交了事务 confirm 确定下数据，查询try的数据是否正确 cancle 回滚数据，把try的数据回滚掉 XA（很少使用了） 主要限制 必须要拿到所有数据源，而且数据源还要支持XA协议。 性能比较差，要把所有涉及到的数据都要锁定，是强一致性的，会产生长事务。 使用范围（资源管理方面的控制） 适用于单体架构 概述和与原理 XA协议是由X/Open组织提出的一个分布式事务处理规范，目前MySQL中只有InnoDB存储引擎支持XA协议。 其中有几个概念： AP 代表我们的应用程序

分布式事务Saga (一) TCC vs Saga 分布式事务Saga（二）事务管理者SagaTransactionalAspect 分布式事务Saga（三）事务参与方管理SagaParticipantAspect 分布式事务Saga（四）事务恢复SagaRecoveryManager 文章目录 TCC流程 支付服务在调用try阶段失败的事务回滚 本项目Saga流程 saga 正常流程图 saga 异常流程图 结论 项目地址： https://github.com/yangxb2010000/saga 该项目的实现本质上说不是一个严格意义上的Saga实现，更像是一个简化版的TCC事务 先对比一下Saga与TCC的区别 TCC流程 Try 预留资源 （如：库存服务的预占库存，支付服务的冻结部分账户余额） Confirm 如果所有的事务参与者try 操作都执行成功了，就会调用所有事务参与者的confirm操作，确认资源。（如：库存服务的减库存，支付服务的扣减账户余额） Cancel 如果有事务参与者在try阶段执行失败，就调用所有已执行try阶段成功的参与方的cancel方法，释放try阶段占用的资源（如：库存服务的释放预占库存，支付服务的释放冻结的账户余额） ####正常逻辑时序图 支付服务在调用try阶段失败的事务回滚 本项目Saga流程 confirm 直接执行资源操作，（如