分布式事务

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

出处： https://github.com/clsaa/Distributed-Transaction-Notes 。 作者总结得很全面，做个笔记搬运。 一、 两阶段提交(2PC) 一个基于两阶段提交协议的分布式事务框架(LCN) 二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常，二阶段提交也被称为是一种协议(Protocol))。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。 所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。 1. 准备阶段 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志

分布系统中，如何保证数据的一致性、原子性，分布式事务。分布式事务分为两大类，柔性事务、刚性事务。 一、方法论篇 分布式事务主要分为两部分，刚性事务和柔性事务。刚性事务主要针对DB层面，严格保证事务的原子性要么都成功，要么执行失败，全部回滚。 柔性事务，相对于刚性事务来的，为了保证DB的利用率，以及系统的吞吐量，不会长时间锁定DB资源，在事务执行失败之后不会进行回滚，而是采用补偿的方式保证数据的最终一致性，所以柔性事务又叫补偿型事务。先来介绍刚性事务。 1.1刚性事务 X/Open XA 协议， 最早的分布式事务模型是 X/Open 国际联盟提出的 X/Open Distributed Transaction Processing（DTP）模型，也就是大家常说的 X/Open XA 协议，简称XA 协议。 名词解释： 其中应用程序(Application Program ，简称AP)：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。 资源管理器(Resource Manager，简称RM)：Rm管理计算机共享的资源，许多软件都可以去访问这些资源，资源包含比如数据库、文件系统、打印机服务器等。 事务管理器(Transaction Manager ，简称TM)：负责管理全局事务，分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。 操作过程 第一阶段

什么是JTA？ JTA全称Java Transaction API ，即Java事务API，英文解释： Java Transaction API (JTA) specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications. JTA是一种高层的，与实现无关的，与协议无关的API，应用程序和应用服务器可以使用JTA来访问事务。 JTA允许应用程序执行分布式事务处理--在两个或多个网络计算机资源上访问并且更新数据，这些数据可以分布在多个数据库上。JDBC驱动程序的JTA支持极大地增强了数据访问能力。 JTA的主要接口： 位于javax.transaction包中 a、UserTransaction接口：让应用程序得以控制事务的开始、挂起、提交、回滚等。由Java客户端程序或EJB调用。 b、TransactionManager 接口：用于应用服务器管理事务状态 c、Transaction接口：用于执行相关事务操作 d、XAResource接口

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说

1、分布式事务 1) 聊聊分布式事务，再说说解决方案 https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html 2) 分布式系统事务一致性解决方案 http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency 3) 从银行转账失败到分布式事务：总结与思考 https://www.cnblogs.com/xybaby/p/7465816.html 4) 详解Mysql分布式事务XA（跨数据库事务） https://blog.csdn.net/soonfly/article/details/70677138 5) MySQL学习之——锁(行锁、表锁、页锁、乐观锁、悲观锁等) https://blog.csdn.net/mysteryhaohao/article/details/51669741 来源： https://www.cnblogs.com/AndrewGhost/p/9102511.html

在一个基于SOA架构的分布式系统体系中，服务（Service）成为了基本的功能提供单元，无论与业务流程无关的基础功能，还是具体的业务逻辑，均实现在相应的服务之中。服务对外提供统一的接口，服务之间采用标准的通信方式进行交互，各个单一的服务精又有效的组合、编排成为一个有机的整体。在这样一个分布式系统中某个活动（Activity）的实现往往需要跨越单个服务的边界，如何协调多个服务之间的关系使之为活动功能的实现服务，涉及到SOA一个重要的课题：服务协作（Service Coordination）。而具体来讲，一个分布式的活动可能会执行几秒钟，比如银行转帐；也可能执行几分钟、几个小时、几天甚至更长，比如移民局处理移民的申请。事务，无疑是属于短暂运行服务协作（Short-Running Service Coordination）的范畴。 一、 什么是事务（Transaction） 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。事务具有如下四个属性，根据其首字母，我们一般将其称为事务的ACID四大属性： 原子性（Atomicity）： “原子”这个词的本义就是不可分割的意思

1 分布式概述 早起我们使用单体架构，即所有的服务都部署在一台服务器的一个进程中，随着互联网的发展，逐步演进为分布式架构，多个服务分别部署在不同机器的不同进程中。 2 Zookeeper概述 Zookeeper是一个开源的分布式协调服务，提供分布式数据一致性解决方案，分布式应用程序可以实现数据发布订阅、负载均衡、命名服务、集群管理分布式锁、分布式队列等功能。 Zookeeper提供了分布式数据一致性的解决访问，那么什么是分布式数据一致性？ 如上图所示，有用户user在DB1中修改balance为900，如果user下一次read请求到DB2数据库的时候，此时DB1数据库的数据还没及时更新到DB2中，就会造成整个数据库集群数据不一致。 数据一致性分为强一致性和最终一致性，强一致性指的是如果数据不一致，就不对外提供数据服务，保证用户读写的数据始终是一致的。数据强一致性值需要通过锁机制即可解决，在案例中通过在DB2没有从DB1同步数据之前上锁，不对外提供读操作。只要当同步完成以后才对外提供服务。而最终一致性要求数据最终同步即可，没有实时要求。 3 CAP原则 CAP在分布式系统中主要指的是一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。 一致性：一致性指的就是强一致性。 可用性：系统提供的服务一直处于可用状态

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阶段真的出错了