分布式事务总结范文 第一篇
技术标签： 分布式
提交或回滚 ②Transaction Manager（TM事务管理器）：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议 ③Resource Manager（RM资源管理器）：控制分支事务,负责分支注册、状态汇报,并接受事务协调的指令,驱动分支(本地)事务的提交和回滚 处理过程： 原理简介： 4.总结：
感觉，协调各个分支事务执行事务 TM（transaction manager）：事务管理器 --- 控制全局事务的边界，事务开启者和全局提交或全局回滚的最终决议者 RM（resouce manager）：资源管理器 --- 控制分支事务,分支事务的执行者 具体执行过程： 1.TM开启全局事务，生成全局唯一事务ID（XID） 在链路中传播 3.RM向TC注册分支事务 4.TM向TC发出事务
/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的...(Transaction Manager)：事务管理器。负责协调和管理事务 RM(Resource Manager)：资源管理器。可以理解为数据库或者JMS。 他们三者的关系： AP通过TM来操作
在X/OpenDTP事务模型中，定义了三个角色 AP: application, 应用程序，也就是业务层。哪些操作属于一个事务，就是AP定义的 RM： Resource Manager，资源管理器。一般是数据库，也可以是其他资源管理器，比如消息队列， 文件系统 TM： Transaction Manager ，事务管理器、事务协调者，负责接收来自用户程序（AP）发起的XA事务指令，并调度和协调
驱动全局事务的提交或回滚。 TM transaction manager 事务管理器 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。 RM resource manager 资源管理器 控制分支事务，负责分支注册、状态汇报，并接受事务协调器的指令，驱动分支（本地）事务提交或回滚。 流程 TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID
分布式事务总结范文 第二篇
前面介绍的可靠消息队列方案能保证最终的结果是相对可靠的，过程也足够简单，但是可靠消息队列的整个实现过程完全没有任何隔离性可言。虽然在有些业务中，有没有隔离性不是很重要，比如说搜索系统。
但在有些业务中，一旦缺乏了隔离性，就会带来许多麻烦，比如下面一个简化版的订销存交易流程：
假设用户下完订单通知库存服务扣减库存失败时，比如原本是10件商品卖了1件剩余9件，但由于库存DB操作失败，导致库存还是10件，这时就出现了数据不一致的情况，此时如果有其它用户也进行了购买操作，则可能出现超卖的问题。
如果采用2PC的解决方案，在整个交易成功完成或者失败回滚之前，其它用户的操作将会处于阻塞等待的状态，这会大大的降低系统的性能和用户体验。
如果业务需要隔离，通常就应该重点考虑 TCC（Try-Confirm-Cancel）方案，TCC天生适用于需要强隔离性的分布式事务中，它是由数据库专家帕特 · 赫兰德（Pat Helland）在 20_ 年撰写的论文《Life beyond Distributed Transactions: An Apostate’s Opinion》中提出的。
在具体实现上，TCC 的操作其实有点儿麻烦和复杂，它是一种业务侵入性较强的事务方案，要求业务处理过程必须拆分为“预留业务资源”和“确认 / 释放消费资源”两个子过程。另外，你看名字也能看出来，TCC 的实现过程分为了三个阶段：
TCC是基于BASE理论的类2PC方案，根据业务的特性对2PC的流程进行了优化，与2PC的区别在一些步骤的细节上，如下图：
可以看出，不同于2PC第一阶段的Prepare，TCC在Try阶段主要是对资源的预留操作这类的轻量级操作，比如冻结部分库存数量，它不需要像2PC在第二阶段完成之后才释放整个资源，也就是它不需要等待整个事务完成后才进行提交，这时其它用户的购买操作可以继续正常进行，因此它的阻塞范围小时间短暂，性能上比2PC方案要有很大的提升。
另外，TCC是位于用户代码层面，而不是在基础设施层面，这为它的实现带来了较高的灵活性，可以根据需要设计资源锁定的粒度。TCC 在业务执行时只操作预留资源，几乎不会涉及锁和资源的争用，具有很高的性能潜力。
但是 TCC要求所有的事务参与方都必须要提供三个操作接口：Try/Confirm/Cancel，带来了更高的开发成本和业务侵入性，意味着有更高的开发成本和更换事务实现方案的替换成本，特别是对一些难以改动的老旧系统来说甚至是不可行的。
分布式事务总结范文 第三篇
事务 数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。 思考一个问题？为什么要引入事务，事务帮助我们解决了什么问题？ 事务的产生...
分布式事...
注：以下内容摘自： XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口，在事务管理器（Transac...
1 什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2 分布式事务产生的原因 数据库分库分表 当...
分布式事务总结范文 第四篇
这是一个根据业务特性进行妥协的一种方案，根据实际的业务场景对立面的数据重要性进行划分，放弃传统的全局数据一致，允许部分不重要的数据出现不一致，但不会对业务产生重大影响。
但是我们可以依据实际的电商购物场景进行取舍：允许少卖，但不能超卖。于是我们可以先扣库存，库存扣减成功后才创建订单并关联库存，若扣库存失败则不创建订单。有以下几种情况：
对于第2种情况，会出现多扣库存的情况，这时可以基于状态进行补偿，就不会出现超卖的问题了：根据库存流水记录查找那些一段时间内未关联订单的库存记录进行撤销操作。这个和我们在12306上的买车票，如果30分钟内未支付的话车票会被释放，是一个道理。
这是一种事后处理机制，即使补偿失败，也不会有严重后果，对业务来说也是可接受的，大不了手工重新上架。
分布式事务总结范文 第五篇
Try 阶段是做完业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的 Conrm 一起才能真正构成一个完整的业务逻辑。 Confirm 阶段是做确认提交，Try 阶段所有分支事务执行成功后开始执行 Conrm。通常情况下，采用 TCC 则认为 Conrm 阶段是不会出错的。即：只要 Try 成功，Conrm 一定成功。若 Conrm 阶段真的出错了，需引入重试机制或人工处理。 Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用 TCC 则认为 Cancel 阶段也是一定成功的。若 Cancel 阶段真的出错了，需引入重试机制或人工处理。
分布式事务总结范文 第六篇
分布式事务的解决方案 一。为什么会有分布式事务 假设有如下架构，两个应用节点，一个数据库，一个负载均衡器。在这个架构下，一个月的数据量就会超过 3000W，而随着数据量的不断扩大，对于表的相关查询操作的性能开销就越来越大，并且响应耗时也越来越长。这个时候需要考虑到数据库的优化问题，也就是对数据库进行分表分库，达到分摊数据库压力以及减少数据库单表数据量的目的。分库分表以后，一方面分担了单库带来的性能...
什么是分布式系统？ 分布式系统是若干独立计算机的集合，这计算机对用户来说就像单个相关系统。 分布式系统的优点 * 应用分层(模块化)：系统可按业务类型拆分成多个应用，按照结构还可分为接口层、服务层等。 * 增大系统的容量：多个服务多个应用，分开处理不同的业务 ...
5月28日，中国年度最具影响力之一的行业盛会20_HRoot中国人力资本论坛在北京盛大开启，「Spark领航者」HRoot 20_年度人力资源服务机构榜单在会上隆重揭晓，作为国内人力资源管理软件高端定制领航者，红海云在「人力资源管理软件」赛道成功上榜，与行业不同领域的卓越人力资源服务机构同仁共同推动建立全新的行业标准。 据悉，本次榜单评选邀请了来自各行业的顶尖专家、学者、企业家共同参与评审，从...
