分布式事务

本文曾经收录到Github仓库，该仓库蕴含计算机根底、Java根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等外围知识点，欢送star~ Github地址：https://github.com/Tyson0314/Java-learning 简介事务事务是应用程序中一系列紧密的操作，所有操作必须胜利实现，否则在每个操作中所作的所有更改都会被吊销。也就是事务具备原子性，一个事务中的一系列的操作要么全副胜利，要么一个都不做。事务应该具备 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 个性。 分布式事务分布式事务是指事务的参与者，反对事务的服务器，资源服务器以及事务管理器别离位于分布式系统的不同节点之上。通常一个分布式事务中会波及对多个数据源或业务零碎的操作。分布式事务也能够被定义为一种嵌套型的事务，同时也就具备了ACID事务的个性。 强一致性、弱一致性、最终一致性强一致性 任何一次读都能读到某个数据的最近一次写的数据。零碎中的所有过程，看到的操作程序，都和全局时钟下的程序统一。简言之，在任意时刻，所有节点中的数据是一样的。 弱一致性 数据更新后，如果能容忍后续的拜访只能拜访到局部或者全副拜访不到，则是弱一致性。 最终一致性 不保障在任意时刻任意节点上的同一份数据都是雷同的，然而随着工夫的迁徙，不同节点上的同一份数据总是在向趋同的方向变动。简略说，就是在一段时间后，节点间的数据会最终达到统一状态。 因为分布式事务计划，无奈做到齐全的ACID的保障，没有一种完满的计划，可能解决掉所有业务问题。因而在理论利用中，会依据业务的不同个性，抉择最适宜的分布式事务计划。 分布式事务的根底CAP实践Consistency（一致性）：数据统一更新，所有数据变动都是同步的（强一致性）。 Availability（可用性）：好的响应性能。 Partition tolerance（分区容错性） ：可靠性。 定理：任何分布式系统只可同时满足二点，没法三者兼顾。 CA零碎（放弃P）：指将所有数据（或者仅仅是那些与事务相干的数据）都放在一个分布式节点上，就不会存在网络分区。所以强一致性以及可用性失去满足。 CP零碎（放弃A）：如果要求数据在各个服务器上是强统一的，然而网络分区会导致同步工夫有限缩短，那么如此一来可用性就得不到保障了。保持事务ACID（原子性、一致性、隔离性和持久性）的传统数据库以及对后果一致性十分敏感的利用通常会做出这样的抉择。 AP零碎（放弃C）：这里所说的放弃一致性，并不是齐全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。如果即要求零碎高可用又要求分区容错，那么就要放弃一致性了。因为一旦产生网络分区，节点之间将无奈通信，为了满足高可用，每个节点只能用本地数据提供服务，这样就会导致数据不统一。一些恪守BASE准则数据库，（如：Cassandra、CouchDB等）往往会放宽对一致性的要求（满足最终一致性即可），一次来获取根本的可用性。 BASE实践BASE 是 Basically Available(根本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩大。 根本可用:分布式系统在呈现故障时，容许损失局部可用性能，保障外围性能可用。软状态:容许零碎中存在中间状态，这个状态不影响零碎可用性，这里指的是CAP中的不统一。最终统一:最终统一是指通过一段时间后，所有节点数据都将会达到统一。BASE解决了CAP中实践没有网络提早，在BASE中用软状态和最终统一，保障了提早后的一致性。BASE和 ACID 是相同的，它齐全不同于ACID的强一致性模型，而是通过就义强一致性来取得可用性，并容许数据在一段时间内是不统一的，但最终达到统一状态。 分布式事务解决方案分布式事务的实现次要有以下 6 种计划： 2PC 计划TCC 计划本地音讯表MQ事务Saga事务最大致力告诉计划2PC计划2PC计划分为两阶段: 第一阶段：事务管理器要求每个波及到事务的数据库预提交(precommit)此操作，并反映是否能够提交. 第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据。 长处： 尽量保障了数据的强统一，实现老本较低，在各大支流数据库都有本人实现，对于MySQL是从5.5开始反对。 毛病: 单点问题:事务管理器在整个流程中表演的角色很要害，如果其宕机，比方在第一阶段曾经实现，在第二阶段正筹备提交的时候事务管理器宕机，资源管理器就会始终阻塞，导致数据库无奈应用。同步阻塞:在准备就绪之后，资源管理器中的资源始终处于阻塞，直到提交实现，开释资源。数据不统一:两阶段提交协定尽管为分布式数据强一致性所设计，但依然存在数据不一致性的可能，比方在第二阶段中，假如协调者收回了事务commit的告诉，然而因为网络问题该告诉仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到告诉始终处于阻塞状态，这时候就产生了数据的不一致性。总的来说，2PC计划比较简单，老本较低，然而其单点问题，以及不能反对高并发（因为同步阻塞）仍然是其最大的弱点。 TCCTCC 的全称是：Try、Confirm、Cancel。 Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行 锁定或者预留。Confirm 阶段：这个阶段说的是在各个服务中执行理论的操作。Cancel 阶段：如果任何一个服务的业务办法执行出错，那么这里就须要 进行弥补，就是执行曾经执行胜利的业务逻辑的回滚操作。（把那些执行胜利的回滚）举个简略的例子如果你用100元买了一瓶水， Try阶段:你须要向你的钱包查看是否够100元并锁住这100元，水也是一样的。 如果有一个失败，则进行cancel(开释这100元和这一瓶水)，如果cancel失败不论什么失败都进行重试cancel，所以须要放弃幂等。 如果都胜利，则进行confirm,确认这100元扣，和这一瓶水被卖，如果confirm失败无论什么失败则重试(会依附流动日志进行重试)。 这种计划说实话简直很少人应用，然而也有应用的场景。因为这个事务回滚实际上是重大依赖于你本人写代码来回滚和弥补了，会造成弥补代码微小。 本地音讯表本地音讯表的外围是将须要分布式解决的工作通过消息日志的形式来异步执行。消息日志能够存储到本地文本、数据库或音讯队列，再通过业务规定主动或人工发动重试。人工重试更多的是利用于领取场景，通过对账系统对预先问题的解决。 对于本地音讯队列来说外围是把大事务转变为小事务。还是举下面用100元去买一瓶水的例子。 1.当你扣钱的时候，你须要在你扣钱的服务器上新减少一个本地音讯表，你须要把你扣钱和写入减去水的库存到本地音讯表放入同一个事务(依附数据库本地事务保障一致性。 2.这个时候有个定时工作去轮询这个本地事务表，把没有发送的音讯，扔给商品库存服务器，叫他减去水的库存，达到商品服务器之后这个时候得先写入这个服务器的事务表，而后进行扣减，扣减胜利后，更新事务表中的状态。 3.商品服务器通过定时工作扫描音讯表或者间接告诉扣钱服务器，扣钱服务器本地音讯表进行状态更新。 4.针对一些异常情况，定时扫描未胜利解决的音讯，进行从新发送，在商品服务器接到音讯之后，首先判断是否是反复的，如果曾经接管，在判断是否执行，如果执行在马上又进行告诉事务，如果未执行，须要从新执行须要由业务保障幂等，也就是不会多扣一瓶水。 本地音讯队列是BASE实践，是最终统一模型，实用于对一致性要求不高的。实现这个模型时须要留神重试的幂等。 MQ事务基于 MQ 的分布式事务计划其实是对本地音讯表的封装，将本地音讯表基于 MQ 外部，其余方面的协定根本与本地音讯表统一。 ...

1 背景市面上常见的有，2pc/3pc、tcc、saga等常见的分布式事务解决方案，然而理论施行起来框架比拟重，设计开发比拟繁琐，不易于疾速开发上手。本文提供一种基于柔性事务设计的简略易上手的分布式事务设计方案，用于解决常见的分布式事务常见场景。 2 常见分布式事务场景2.1 同步场景常见的场景，办法内依赖内部微服务多个同步接口，等同步接口返回再开展后续逻辑，如下图1形容。 图1 分布式事务同步场景 存在的问题：B/C失败后，A/B不能回滚，造成数据不统一？ 2.2 异步场景办法内依赖内部微服务多个同步接口同时，本地事务提交并收回异步MQ，如下图2形容。 图2 分布式事务异步场景 存在的问题：询价零碎无奈保障本地事务和mq音讯的发送同时胜利或失败，会造成数据不统一。 3 解决方案3.1 数据模型设计事务表：记录每次同步办法执行的状态，包含：1-进行中（同步办法执行开始）、2-已实现（同步办法执行胜利）、3-失败（同步办法执行失败）、4-已回滚（回滚办法执行胜利）； 办法调用表：记录一个残缺的事务内所有办法的执行前入参、同步办法接口、回滚接口、回滚入参、办法执行程序，如下图3形容： 图3 事务服务数据模型 3.2 设计原理原理：一个残缺事务内，1.首先每个办法提供回滚接口，其次，事务内每次同步办法执行时，优先保护入参数据到事务表，不便后续做回滚弥补；2.整个事务内某一个办法执行失败时，完结整个事务，并更新事务表状态=失败；3.事务表通过轮询状态status=3(失败)事务，调用回滚接口，利用回滚入参进行接口弥补；4.回滚逻辑：找到事务表中失败的执行办法的程序值，只调用小于失败程序值的所有回滚接口、入参，留神并不回滚失败值的接口，并依据程序倒序进行接口回滚弥补。 图4 回滚原理图 3.3 执行时序 图5 回滚执行时序图 3.4 回滚失败解决计划：事务服务的高可用保障：柔性事务前提是保障事务服务高可用性，重点保障；回滚服务重试机制：回滚接口失败重试机制，保证数据一致性；为了防止架构复杂度，做日志记录、报警、人工解决。4 留神问题回滚服务的幂等性：回滚做好业务防重和零碎防重，避免因为回滚带来的业务数据不统一；脏数据：整个事务中某一办法执行失败，后面调用办法的数据作为脏数据应用。简略的解决方案：依赖事务表整个事务执行状态来决定是否应用脏数据。但毛病就是这样会耦合业务逻辑；中心化：整个事务的保护齐全依赖事务服务实现，须要保障事务服务的高可用性；实时性：事务保护本计划通过定时工作保护，如果业务场景有实时性要求，形式能够改为：在整个事务中某一办法执行失败时，catch异样，catch内更新工作状态胜利时，间接进行回滚逻辑调用。5 总结除了通过惯例本地大事务保障事务完整性计划，本次计划提供了一套基于柔性事务回滚弥补的形式来保障分布式事务，通过保护事务服务和事务服务中心对应数据表，从而保障整个分布式事务的完整性。实现形式简略、轻量、易于操作，不便地解决了常见分布式事务场景。 作者：郑朋辉

文｜ 赵新（花名：于雨 ) :蚂蚁团体 Seata 我的项目开源负责人、凋谢原子开源基金会代码奉献之星 郭成（花名：星北 ) ：Seata-php 我的项目独特发起人、蚂蚁团体技术专家 刘岳健：Seata-php 我的项目独特发起人、Hyperf 开发组成员、广东快客电子商务有限公司高级后端工程师 本文 5894 字 浏览 12 分钟 导语艰深地讲，seata-php 是 Seata 的 PHP 语言实现，它实现了 Java 和 PHP 之间的互通，让 PHPer 也能应用 seata-php 来实现分布式事务。 Seata 是一个十分成熟的分布式事务框架，在 Java 畛域是事实上的分布式事务技术标准平台。Seata 目前正在构建其多语言体系[1]，整个体系蕴含了目前罕用的五大类语言：Java、Go、Python、JS 和 PHP。目前的态势是后四种语言都根据 Seata Java 版本构建起对应语言的实现。 除了谋求 Seata 多语言体系过程中因为开源价值要求构建 Seata 的 PHP 版本这个起因外，作为构建起 Web 1.0 时代技术根底 LAMP 架构中的要角，PHP 语言在电商和金融交易场景下仍然被宽泛应用。而这些场景对数据一致性要求十分强烈，这是构建 seata-php 最大的诱因，也是其技术价值所在。 PART. 1--Seata 架构与多语言体系 图片来自 Seata 官网Seata 总体架构由如下角色形成： - 事务协调器 Transaction Coordinator ...

综述：日常需要常常须要用到分布式事务一致性保障，踩坑摸索中积攒了一些教训，联合各种内外部材料，对立做一次梳理，并在最初附上一些实践经验 举例一个业务场景：银行账户A 转账给银行账户 B 100 元引入问题和要求： A-100 和 B+100 都胜利，或都失败转账前 A+B 总额 == 转账后 A+B 总额同一段时间多笔转账间尽量可能并行且不相互影响转账实现后数据永恒保留不失落本地（单机）事务场景如果咱们的业务零碎不简单，能够在一个数据库、一个服务内对数据进行批改，实现转账，那么，咱们能够利用数据库事务，保障转账业务的正确实现。现有的关系型数据库在这方面曾经十分欠缺了 在单机数据库场景下，事务保障 ACID 要求 摘自维基百科： 原子性（Atomicity）：一个事务（transaction）中的所有操作，或者全副实现，或者全副不实现，不会完结在两头某个环节。事务在执行过程中产生谬误，会被回滚（Rollback）到事务开始前的状态，就像这个事务素来没有执行过一样。即，事务不可分割、不可约简。[1]一致性（Consistency）：在事务开始之前和事务完结当前，数据库的完整性没有被毁坏。这示意写入的材料必须完全符合所有的预设束缚、触发器、级联回滚等。[1]事务隔离（Isolation）：数据库容许多个并发事务同时对其数据进行读写和批改的能力，隔离性能够避免多个事务并发执行时因为穿插执行而导致数据的不统一。事务隔离分为不同级别，包含未提交读（Read uncommitted）、提交读（read committed）、可反复读（repeatable read）和串行化（Serializable）。[1]持久性（Durability）：事务处理完结后，对数据的批改就是永恒的，即使系统故障也不会失落。[1]在常见互联网业务场景下，都是读多写少，所以比拟多都是用 MVCC 技术，用版本号和快照的计划实现高并发（repeatable read）下的一致性 分布式事务现实情况下，绝大多数的互联网业务都是分布式系统，服务、资源、数据库等都不是单机部署，甚至可能横跨多家公司、运营商。所以在这种场景下，原有的本地事务保障曾经无奈满足需要 数据库外部分布式事务一些分布式数据库原生外部反对事务个性，能够大大减少业务方操作事务的复杂性，根本由数据库组件来解决问题目前常见的反对分布式事务的数据库举例： TDSQL（腾讯）TBase（腾讯）TiDB（PingCAP）Spanner（Google）OceanBase（阿里巴巴）这种计划比拟适宜数据位于同一个数据库组件，只须要可能保障并发操作不会造成数据不统一的业务 更宽泛场景下的的异构分布式事务更多时候，咱们的业务流程都比较复杂，比方上网买个女朋友。外围的流程至多有： 下单领取扣库存发货每个步骤可能都是由不同服务操作，相干的数据存储在不同数据库中。这种状况下，难以有对立的版本号，MVCC 伎俩无奈应用目前为止还没有反对跨数据库的严格一致性计划 绝对应于本地事务的强 ACID 要求，分布式事务场景下，为了面向高可用、可扩大等要求，个别会进行取舍，升高局部一致性和隔离性的要求，遵循 BASE 实践： 根本业务可用（Basic Availability）软状态（Soft state）最终统一（Eventual consistency）分布式事务中的 ACID 状况： 原子性：严格遵循，采纳相似 UNDO 的形式实现一致性：实现后的一致性严格遵循；事务中的一致性可适当放宽隔离性：大量事务能够并行持久性：严格遵循目前业界常见的分布式事务解决方案有 XA（两阶段提交、三阶段提交）TCCSAGA本地音讯表事务音讯最大致力告诉AT 事务模式XAXA 是由 X/Open 组织提出的分布式事务标准，这个标准次要定义了（全局）事务管理器（TM） 和（部分）资源管理器（RM）之间的接口。本地数据库如 MySQL 对应的是这里的 RM 角色XA 由一个或多个资源管理器（RM），一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成。这三个角色概念 RM、TM、AP 是经典的角色划分，须要见名知意 目前支流的数据库根本都反对 XA 事务 两阶段提交顾名思义就是须要分两步提交事务：第一阶段（prepare)：事务管理器向所有本地资源管理器发动申请，询问是否是 ready 状态，所有参与者都将本事务是否胜利的信息反馈发给协调者第二阶段（commit/rollback）：事务管理器依据所有本地资源管理器的反馈，告诉所有本地资源管理器，各自为政地在所有分支上提交或者回滚 长处： 简略容易了解，开发较容易毛病： 同步阻塞问题：prepare 阶段锁住了资源，其余参与者须要等前一个参与者开释，并发度低单点问题：事务管理器呈现故障，整个零碎不可用不统一的可能：commit/rollback 阶段，如果事务管理器只发送了局部 commit 音讯，此时如果事务管理宕机（极其状况某些参与者也一起宕机），则难以保障所有参与者一致性失常不统一的可能，能够引入超时机制和互询机制来很大水平解决：对于协调者来说如果在指定工夫内没有收到所有参与者的应答，则能够主动退出 WAIT 状态，并向所有参与者发送 rollback 告诉。对于参与者来说如果位于 READY 状态，然而在指定工夫内没有收到协调者的第二阶段告诉，则不能果断地执行 rollback 操作，因为协调者可能发送的是 commit 告诉，这个时候执行 rollback 就会导致数据不统一。此时，咱们能够染指互询机制，让参与者 A 去询问其余参与者 B 的执行状况。如果 B 执行了 rollback 或 commit 操作，则 A 能够大胆的与 B 执行雷同的操作；如果 B 此时还没有达到 READY 状态，则能够推断出协调者收回的必定是 rollback 告诉；如果 B 同样位于 READY 状态，则 A 能够持续询问另外的参与者。只有当所有的参与者都位于 READY 状态时，此时两阶段提交协定无奈解决，将陷入长时间的阻塞状态。 ...

分布式事务分布式事务是指会波及到操作多个数据库的事务，其实就是将对同一库事务的概念扩充到了对多个库的事务。目标是为了保障分布式系统中的数据一致性。 分布式事务处理的要害是： 须要记录事务在任何节点所做的所有动作；事务进行的所有操作要么全副提交，要么全副回滚。1.CAP实践 分布式系统的三个指标： 一致性 Consistency：对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。可用性 Availability：任何客户端的申请都能失去响应数据，不会呈现响应谬误。分区容错性 Partition tolerance：因为分布式系统通过网络进行通信，网络是不牢靠的。当任意数量的音讯失落或提早达到时，零碎仍会持续提供服务，不会挂掉。一个分布式系统，不可能同时做到这三点； 对于一个分布式系统而言，P是前提，必须保障，因为只有有网络交互就肯定会有提早和数据失落，这种情况咱们必须承受，必须保证系统不能挂掉。所以只剩下C、A能够抉择。要么保证数据一致性（保证数据相对正确），要么保障可用性（保证系统不出错）。 当抉择了C（一致性）时，如果因为网络分区而无奈保障特定信息是最新的，则零碎将返回谬误或超时。 当抉择了A（可用性）时，零碎将始终解决客户端的查问并尝试返回最新的可用的信息版本，即便因为网络分区而无奈保障其是最新的。 CP架构 因为网络问题，节点A和节点B之前不能相互通信。当有客户端（上图Actor）向节点A进行写入申请时（筹备写入Message 2），节点A会不接管写入操作，导致写入失败，这样就保障了节点A和节点B的数据一致性，即保障了Consisteny（一致性）。 而后，如果有另一个客户端（上图另一个Actor）向B节点进行读申请的时候，B申请返回的是网络故障之前所保留的信息（Message 1），并且这个信息是与节点A统一的，是整个零碎最初一次胜利写入的信息，是能失常提供服务的，即保障了Partition tolerance（分区容错性）。 AP架构 因为网络问题，节点A和节点B之前不能相互通信。当有客户端（上图Actor）向节点A进行写入申请时（筹备写入Message 2），节点A容许写入，申请操作胜利。但此时，因为A和B节点之前无奈通信，所以B节点的数据还是旧的（Message 1）。当有客户端向B节点发动读申请时候，读到的数据是旧数据，与在A节点读到的数据不统一。但因为零碎能照常提供服务，所以满足了Availability（可用性）要求。 注意事项对于开发者而言，构建服务的时候须要依据业务个性作出衡量思考，哪些点是以后零碎能够取舍的，哪些是应该重点保障的。 如在某个电商零碎中，属于用户模块的数据（账密、钱包余额等）对一致性的要求很高，就能够采纳CP架构。 而对于一些商品信息方面的数据对一致性要求没那么高，但为了关照用户体验，所以对可用性要求更高一些，那么这个模块的数据就能够采纳AP架构。 注：只能抉择CP和AP，无奈抉择CA，这句话成立的前提条件是在零碎产生了网络故障的状况下。在网络失常状况下，CA是能够实现的，咱们也须要去保障在绝大多数工夫下的CA架构。 2.Base实践核心思想：既是无奈做到强一致性（Strong consistency），但每个利用都能够依据本身的业务特点，采纳适当的形式来使零碎达到最终一致性（Eventual consistency）。Basically Available 根本可用假如零碎，呈现了不可预知的故障，但还是能用，相比拟失常的零碎而言会有响应工夫和性能上的损失： 响应工夫上的损失：失常状况下的搜索引擎0.5秒即返回给用户后果，而根本可用的搜索引擎能够在2秒作用返回后果。性能上的损失：在一个电商网站上，失常状况下，用户能够顺利完成每一笔订单。然而到了大促期间，为了爱护购物零碎的稳定性，局部消费者可能会被疏导到一个降级页面。Soft state(软状态)绝对于原子性而言，要求多个节点的数据正本都是统一的，这是一种“硬状态”。 软状态指的是：容许零碎中的数据存在中间状态，并认为该状态不影响零碎的整体可用性，即容许零碎在多个不同节点的数据正本存在数据延时。 如先把订单状态改成已领取胜利，而后通知用户曾经胜利了；剩下在异步发送mq音讯告诉库存服务减库存，即便生产失败,MQ音讯也会从新发送（重试）。 注：不可能始终是软状态，必须有个工夫期限。在期限过后，该当保障所有正本保持数据一致性，从而达到数据的最终一致性。这个工夫期限取决于网络延时、零碎负载、数据复制方案设计等等因素。 Eventually consistent(最终一致性)强一致性读操作要么处于阻塞状态，要么读到的是最新的数据最终一致性通常是异步实现的，读到的数据刚开始可能是旧数据，然而过一段时间后读到的就是最新的数据3.最终一致性解决方案留神可查问操作：业务方须要提供可查问接口，来查问数据信息和状态，供其余服务晓得数据状态。幂等操作：同样的参数执行同一个办法，返回的后果都一样。在分布式环境，难免会呈现数据的不统一，很多时候为了保证数据的统一，咱们都会进行重试。如果不保障幂等，即便重试胜利了，也无奈保证数据的一致性。咱们能够通过业务自身实现实现幂等，比方数据库的惟一索引来束缚；也能够缓存（记录）申请和操作后果，当检测到一样的申请时，返回之前的后果。弥补操作：某些数据存在不失常的状态，须要通过额定的形式使数据达到最终一致性的操作。XA标准XA标准是由 X/Open组织（即当初的 Open Group ）定义的分布式事务处理模型。\XA 一共分为两阶段： 第一阶段（prepare）：即所有的参与者 RM 筹备执行事务并锁住须要的资源。参与者 ready 时，向 TM 报告已准备就绪。 第二阶段 (commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都 ready 后，向所有参与者发送 commit 命令。 目前支流的数据库根本都反对 XA 事务，包含 mysql、oracle、sqlserver、postgre XA标准的组成应用程序（ AP ）事务管理器（ TM ）：交易中间件等资源管理器（ RM ）：关系型数据库等通信资源管理器（ CRM ）：消息中间件等XA标准定义XA标准定义了交易中间件与数据库之间的接口标准（即接口函数），交易中间件用它来告诉数据库事务的开始、完结以及提交、回滚等。而XA接口函数由数据库厂商提供。 ...

1 数据库事务1.1 一般本地事务分布式事务也是事务，事务的 ACID 根本个性仍旧必须合乎： A：Atomic，原子性，事务内所有 SQL 作为原子工作单元执行，要么全副胜利，要么全副失败； C：Consistent，一致性，事务实现后，所有数据的状态都是统一的。如事务内A给B转100，只有A减去了100，B账户则必然加上了100； I：Isolation，隔离性，如果有多个事务并发执行，每个事务作出的批改必须与其余事务隔离； D：Duration，持久性，即事务实现后，对数据库数据的批改被长久化存储。 一般的非分布式事务，在一个过程外部，基于锁依赖于快照读和以后读，比拟好实现 ACID 来保障事务的可靠性。但分布式事务参与方通常在不同机器的不同实例上，原来的部分事务的锁不能保障分布式事务的ACID个性，须要引入新的事务框架，MySQL的分布式事务是基于2PC（二阶段提交）实现，上面具体介绍下2pc分布式事务。 1.2 基于2pc的分布式事务分布式事务有多种实现形式，如2PC（二阶段提交）、3PC（三阶段提交）、TCC（弥补事务）等，MySQL是基于 2PC 实现的分布式事务，上面介绍 2PC 分布式事务实现形式。 两阶段提交：Two-Phase Commit , 简称2PC，为了使基于分布式系统架构下的所有节点在进行事务提交时放弃一致性而设计的一种算法。 2PC的算法思路能够概括为，参与者将操作成败告诉协调者，再由协调者依据所有参与者的反馈情报，决定各参与者是否要提交操作还是停止操作。这里的参与者能够了解为 Resource Manager (RM)，协调者能够了解为 Transaction Manager（TM)。 下图阐明了RM和TM在分布式事务中的运作过程： 第一阶段提交：TM 会发送 Prepare 到所有RM询问是否能够提交操作，RM 接管到申请，实现本身事务提交前的筹备工作并返回后果。 第二阶段提交：依据RM返回的后果，所有RM都返回能够提交，则 TM 给 RM 发送 commit 的命令，每个 RM 实现本人的提交，同时开释锁和资源，而后 RM 反馈提交胜利，TM 实现整个分布式事务；如果任何一个 RM 返回不能提交，则波及分布式事务的所有 RM 都须要回滚。 2 MySQL 分布式事务XAMySQL分布式事务XA是基于下面的2pc框架实现，上面具体介绍MySQL XA相干内容。 2.1 XA事务规范 X/Open 这个组织定义的一套分布式XA事务的规范，定义了标准和API接口，而后由厂商进行具体的实现。 XA标准中分布式事务由AP，RM，TM组成： 如上图，应用程序AP定义事务边界（定义事务开始和完结），并拜访事务边界内的资源。资源管理器RM治理共享的资源，也就是数据库实例。事务管理器TM负责管理全局事务，调配事务惟一标识，监控事务的执行进度，并负责事务的提交、回滚、失败复原等。MySQL实现了XA规范语法，提供了下面的RMs能力，能够让下层利用基于它疾速反对分布式事务。 2.2 MySQL XA语法XA START xid:开启一个分布式事务xid。 XA END xid: 将分布式事务xid置于 IDLE 状态，示意事务内的SQL操作实现。 ...

分布式事务实际 解决数据一致性Socket 是什么以及创建过程一个数据包经由应用程序产生，进入到协定栈中进行各种报文头的包装，而后操作系统调用网卡驱动程序指挥硬件，把数据发送到对端主机。整个过程的大抵的图示如下。 download 咱们大家知道，协定栈其实是位于操作系统中的一些协定的重叠，这些协定包含 TCP、UDP、ARP、ICMP、IP等。通常某个协定的设计都是为理解决某些问题，比如 TCP 的设计就负责安全可靠的传输数据，UDP 设计就是报文小，传输效率高，ARP 的设计是能够通过 IP 地址查问物理（Mac）地址，ICMP 的设计目标是返回谬误报文给主机，IP 设计的目标是为了实现大范畴主机的互联互通。 应用程序比如阅读器、电子邮件、文件传输服务器等产生的数据，会通过传输层协定进行传输，而应用程序是不会和传输层间接建立联系的，而是有一个能够连接应用层和传输层之间的套件，这个套件就是 Socket。 在下面这幅图中，应用程序蕴含 Socket 和解析器，解析器的作用就是向 DNS 服务器发动查问，查问目标 IP 地址。 应用程序的上面就是操作系统外部，操作系统外部包含协定栈，协定栈是一系列协定的重叠。操作系统上面就是网卡驱动程序，网卡驱动程序负责管制网卡硬件，驱动程序驱动网卡硬件实现收发工作。 在操作系统外部有一块用于存放管制信息的存储空间，这块存储空间记录了用于管制通信的管制信息。其实这些管制信息就是 Socket 的实体，或者说存放管制信息的内存空间就是套接字的实体。 这里大家有可能不太明显所以然，所以我用了一下 netstat 命令来给大伙看一下套接字是啥玩意。 咱们在 Windows 的命令提示符中输出 netstat -ano netstat 用于浮现套接字内容 , -ano 是可选选项a 不只浮现正在通信的套接字，还浮现包含尚未开始通信等状态的所有套接字n 浮现 IP 地址和端口号o 浮现套接字的程序 PID我的计算机会出现上面后果。 图中的每一行都相当于一个套接字，每一列也被称为一个元组，所以一个套接字就是五元组（协定、本地地址、内部地址、状态、PID）。有的时候也被叫做四元组，四元组不包含协定。 比如图中的第一行，它的协定就是 TCP，本地地址和近程地址都是 0.0.0.0，这示意通信还没有开始，IP 地址临时还未必定，而本地端口已知是 135，然而近程端口还未知，此时的状态是 LISTENING，LISTENING 示意应用程序已经打开，正在等待与近程主机建立连接（对于各种状态之间的转换，大家可能浏览笔者的这篇文章 TCP ，丫的终于来了！！）最初一个元组是 PID，即过程标识符，PID 就像咱们的身份证号码，能够精确定位唯一的过程。 现在你可能对 Socket 有了一个基本的意识，现在喝口水，劳动一下，让咱们持续探究 Socket。 现在我有个问题，Socket 是如何创建的呢？Socket 是和应用程序一起创建的。应用程序中有一个 socket 组件，在应用程序启动时，会调用 socket 申请创建套接字，协定栈会根据应用程序的申请创建套接字：首先调配一个套接字所需的内存空间，这一步相当于是为管制信息筹备一个容器，但只有容器并没有实际作用，所以你还需要向容器中放入管制信息；如果你不申请创建套接字所需要的内存空间，你创建的管制信息也没有地方存放，所以分配内存空间，放入管制信息缺一不可。至此套接字的创建就已经实现了。 ...

景象互联网的世界与十几年前相比，曾经大不相同。以往的单体服务就能够撑持起大多数的用户需要。然而随着手机等电子产品的遍及，用户想要的服务曾经是越来越简单，各种需要互相关联。而这也给软件开发带来了更多的挑战。为了应酬随时会变动的代码世界，现有的开发趋势都在逐步的化整为零。其中最具代表性的就是微服务的风行。 在软件设计时，咱们常常会说高内聚，低耦合。这其实是对性能职责的确定。而在微服务的设计里，就是要将这些职责明确后拆分进来，再联结起来提供残缺的零碎性能。这其实跟一家企业的运行是一样的，企业须要依据本身的状况去组建各个部门，让业余的人干专门的事，以实现独特的指标。 问题在对于微服务的设计上，曾经有很多成熟的领导计划。比方基于畛域模型的，基于事件驱动的。然而，当各个服务各自为战后，在数据的一致性上，却未能有欠缺的解决方案。或是受性能效率限度，或是实现流程简单。总之，咱们须要采取很多额定的伎俩去解决分布式服务的数据一致性问题。 首先，何为数据一致性？集体了解，它能够是业务上的一致性，即数据库里常常提及的完整性束缚。就像银行的转账流程，其后果导向是一方的账户余额会缩小，另一方的增多。这是咱们在一开始就定义好的数据流程转换，必须要正确；另一种常见的数据一致性是零碎外部为了解决某些瓶颈而不得不思考面对的问题，比方主从复制、数据分片、集群选举等，对于这一块咱们后续有空再钻研。先来看看分布式服务里常常须要保障的业务一致性。 在软件开发行业里，自身就有对业务一致性的解决方案，即事务。对于事务的应用到当初都不会过期，只不过须要在同一个数据源（比方同一个数据库里），他人能力给你保障。然而，在以拆分为核心思想的微服务架构下，数据的变更是会在不同中央产生的，怎么去协调这些变更，以实现定义好的业务后果，是很艰难的。因为不足一个对立的协调管理者来染指，而一旦引入这个概念，又会挑战微服务的核心思想：去中心化，各个模块有可能会从新耦合在一起。 这就是艰难点所在了，咱们心愿各个服务能独立运行，但服务所产生的行为数据又要能配合协调，甚至相互依赖。这就有点纠缠不清的感觉了。 剖析只管分布式服务的数据一致性很简单，但作为软件开发的客人，咱们总得去厘清这外面的逻辑关系，确定边界，而后按对立的领导准则去设计。在这方面，曾经有一个规范的分布式统一解决模型，它是由国内开发规范组织 Open Group 定制的，其外围就像后面提及到的，有一个全局的协调者：事务管理器，外加事务的参与者：资源处理器以及其余辅助组件。咱们常常看到的 2PC ，两阶段提交就是基于此实现的。 两阶段提交对于两阶段提交，它的设计是在数据档次上的一个对立协调者，它对于服务提供方来讲侵入性较少，其治理的指标是将所有参与者波及到的数据进行对立的提交与回滚。 咱们晓得，在以前的本地事务里，当一系列的业务操作执行完后，就能够进行事务的提交/回滚这个确认动作了。而在两阶段提交里，这个确认动作要被提早。之所以要提早，是因为须要事务管理器这个协调者去查看其余参与者是否也将本人的业务流程执行完，只有当所有参与者都反馈执行完，能力进行最初的确认动作。当然，这个确认动作也是会告诉到所有参与者的。 实际上，事务管理器作为全局事务的管理者，它在一开始就染指整个流程了。具体过程如下： 【1】准备阶段(Prepare phase): 事务管理器向所有事务参与者发送事务执行申请，当参与者承受到该音讯后，进行本地事务的执行，记录事务日志，但并不提交事务。在执行完后会将执行后果反馈给协调者，等到后续告诉。 【2】提交阶段(Commit phase):事务管理器依据所有参与者的执行反馈后果决定此次的操作是提交或回滚。若参与者执行失败或者超时，则会告诉所有参与者进行回滚；否则，告诉提交。 能够看到，咱们将本来的事务流程拆分成了多个阶段，再由事务管理器去对立协调这些阶段解决。这个解决形式看起来简略，但外面要思考的因素有很多，例如： 阻塞：对于参与者来讲，因为本地事务的处理结果尚未确定，所以必须要阻塞期待协调者的后续执行指令。单点问题：事务管理器这个协调者很重要，一旦发送故障，那么将无奈进行后续的决策，即事务参与者将会有限的阻塞，直到协调者从新上线。除此之外，两阶段提交在性能效率上也须要掂量思考。此时的全局事务实现工夫曾经不再是简略的 1+1 的计算形式了，而是参与者与协调者的合作实现工夫。 TCC两阶段提交是属于强一致性的解决方案，它在资源管理器上的实现通常是由各个参加数据库来提供对立操作：筹备、提交、回滚。而这一套规范操作也能够由业务来实现，以提供更细的业务粒度以及更好的并发能力，相当于服务间接的参加了全局事务的协调流程，这即所谓的 TCC：Try-Confirm-Cancel 分布式事务。 TCC 分布式事务模型也将整体流程划分了两个阶段，在第一个阶段里，会由事务管理器这个对立协调者去进行所有参与者的业务检查和资源预留，在此阶段并不会真正的执行预期业务动作，只是先 check 前置条件，占有资源。在接下来的第二阶段里，会依据各个参与者的反馈后果，去决定是进行业务的确认操作还是勾销操作。 在 TCC 的设计里，会认为只有所有参与者都 Try 胜利，那么接下来的 Confirm 或 Cancel 操作是必定能胜利，如果失败，那么将须要一直从新或者人工染指。因而，TCC 还得在业务上有幂等保障。 TCC 相当于让业务自定义了筹备、提交、回滚操作，这样能够让开发者决定资源的占有机会，升高锁抵触，进步解决能力。就是对业务的侵入很大，原有的流程须要强行定义出 Try-Confirm-Cancel 的业务操作。 音讯最终统一在理论的开发过程中，咱们会发现有一些简略的分布式事务处理场景，比方签到后积分减少这种。它们可能仅仅是本地事务处理完，而后告诉另外个服务进行资源更新以实现整条链路需要。对于这种简略的分布式事务处理，用户对其不统一的容忍度比拟高，不要求立马失效，只有后果正确。针对这种即时性要求不高的需要，咱们能够应用上面这种最终统一的计划：状态管制+音讯发送+定时查看。 状态管制：对于本地的业务需要要有个状态记录，用于探知以后的解决阶段，以便重试或辅助前面的定时查看。音讯发送：当波及其余服务的资源更新操作时，通过音讯进行解耦，驱动下一个事务流程。定时查看：不再有协调者去兼顾全局事务，各个参与者只负责本人的事务实现状况，定时测验是否由异样状态或后果，触发对应解决流程。如报警告诉、人工兜底。下面的这个最终统一模型，实用于简略流程的分布式服务，或者跟事务想要的成果都搭不上边，更多的是靠音讯告诉，预先解决这种简略伎俩来保障业务的最终统一。如果业务链比较复杂，那就会定义出各种各样的音讯类型，这种反而会让整个零碎难以了解，也不易保护。 总结此次，咱们钻研了数据档次的分布式事务；业务档次的分布式事务；以及最终统一的伪分布式事务。对于这些模型的实现，市面上曾经有些成熟的框架了，比方 Seata，ByteTCC 等。大家能够站在伟人的肩膀上，更深刻的理解其实现流程，验证本人的所思所想。 感兴趣的敌人能够搜一搜公众号「 阅新技术 」，关注更多的推送文章。 能够的话，就顺便点个赞、留个言、分享下，感激各位反对！ 阅新技术，浏览更多的新常识。

为什么须要分布式事务分布式的微服务通常各自有本人的数据源，单机的事务由本机的数据源实现；当一个业务波及多个微服务的多个数据源时，很难保障多个数据源同时胜利、同时失败。 比方：支付宝 转账到 余额宝 1000元 支付宝： 账户A(id, user_id, amount)领取服务pay，转出：update A set amount=amount-1000 where user_id=1;余额宝： 账户B(id, user_id, amount)余额宝服务balance，转入：update B set amount=amount+1000 where user_id=1;领取服务pay和余额宝服务balance，只有同时执行胜利，才算本次转账胜利；只有有一方执行失败，则本次转账失败。 分布式事务的解决方案--2PC2PC(Two Phase Commit protocol)两阶段提交，是强一致性的分布式事务实现形式。 2PC波及的角色： 协调者：coordinator，协调多个参与者进行投票、提交或回滚；参与者：participants，本地事务的执行者； 2PC的解决部署： 投票阶段 协调者告诉参与者执行本地事务，而后进入表决过程；参与者执行本地事务，但不提交，将执行后果回复协调者；提交阶段 协调者收到参与者的执行后果，若均执行胜利，则向所有参与者发送commit；否则，向所有参与者发送rollback；2PC的毛病： 协调者是个单点，存在单点故障；事务提交之前，资源被预留锁定，因为波及多节点的网络交互，导致锁工夫较长，影响并发；分布式事务的解决方案--TCCTCC(Try Confirm Cancel)，是业务层面的分布式事务，TCC要求所有的事务参与者都要实现3个接口： Try: 预处理；Confirm: 确认；Cancel: 勾销；TCC的执行过程： Client向所有事务参与者发送Try操作；若所有事务参与者的Try均胜利，则Client向所有事务参与者发送Confirm，否则发送Cancel；TCC要求事务参与方，都要当时实现Try/Confirm/Cancel接口，对业务代码的侵入性较强。 TCC存在的问题： 空回滚 第一阶段的Try因为音讯失落而产生网络超时，触发第二阶段的Cancel；事务参与方在没有收到Try的状况下，收到了Cancel音讯，称为“空回滚”；“空回滚”的存在，要求事务参与方在实现Cancel接口时，思考未收到Try的状况；防悬挂 第一阶段的Try因为音讯失落而产生网络超时，触发第二阶段的Cancel；事务参与方在没有收到Try的状况下，收到了Cancel音讯，执行“空回滚”；此时，第一阶段的Try音讯又达到，该场景称为“防悬挂”；解决办法： 执行“空回滚”的时候，插入1条记录，状态为已回滚；当Try又回来时，先查问记录，若已存在且已回滚，则不再执行该Try；分布式事务的解决方案--最终一致性基本思路是，将事务音讯进行长久化(Transaction outbox)，通过binlog推送给上游，上游生产胜利后，调用callback到上游，通知上游事务处理完毕。 没有事务的回退流程，通过重试，尽最大致力交付，实质上是最终一致性的解决方案。 事务音讯长久化：Transaction outbox支付宝pay服务执行本地事务，进行A用户扣款，同时记录音讯数据msg，该msg表与pay业务数据在同一个DB中。 支付宝pay服务的本地事务保障，只有实现扣款，msg肯定能保留下来。 begin transaction update A set amount = amount - 1000 where user_id=1; insert into msg(user_id, amount, status) values(1, 1000, 1)end transactioncommit通过binlog推送给上游：Transaction log tailing支付宝的msg表被Canal订阅，而后发送到kafka。通过Canal异步订阅的形式，将两边解耦。 ...

大家好，我是老三，上次发文的时候还是上次发文的时候，这篇文章分享分布式事务，看完要是你们不懂，那肯定是不明确。 从本地事务到分布式事务事务大家应该都晓得，事务将一组操作纳入到一个不可分割的执行单元，这个执行单元里的操作都胜利时能力提交胜利。 简略地说，事务提供一种要么不做，要么全做机制。 ACID咱们先简略理解一下事务的四大个性： A 原子性(Atomicity)一个事务(transaction)中的所有操作，要么全副实现，要么全副不实现，不会呈现局部胜利局部失败的状况。。 C 一致性(Consistency)事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务胜利地实现，那么零碎中所有变动将正确地利用，零碎处于无效状态。如果在事务中呈现谬误，那么零碎中的所有变动将主动地回滚，零碎返回到原始状态。 I 隔离性(Isolation)指的是在并发环境中，当不同的事务同时操纵雷同的数据时，每个事务都有各自的残缺数据空间。由并发事务所做的批改必须与任何其余并发事务所做的批改隔离。事务查看数据更新时，数据所处的状态要么是另一事务批改它之前的状态，要么是另一事务批改它之后的状态，事务不会查看到中间状态的数据。 D 持久性(Durability)指的是只有事务胜利完结，它对数据库所做的更新就必须永恒保留下来。即便产生零碎解体，重新启动数据库系统后，数据库还能复原到事务胜利完结时的状态。 单体事务在单体架构时代，所有的业务只用一个数据库。 单体架构时代事务的是实现很简略，咱们操作的是同一个数据库，利用数据库自身提供的事务机制反对就能够了。 例如咱们比拟相熟的MySQL数据库： 事务的隔离性是通过数据库锁的机制实现的。事务的一致性由undo log来保障：undo log是逻辑日志，记录了事务的insert、update、deltete操作，回滚的时候做相同的delete、update、insert操作来复原数据。事务的原子性和一持久性由redo log来保障：redolog被称作重做日志，是物理日志，事务提交的时候，必须先将事务的所有日志写入redo log长久化，到事务的提交操作才算实现。 具体理解倡议浏览《MySQL技术底细 InnoDB存储引擎》7.2节。分布式事务随着业务倒退，单体架构顶不住了，缓缓进入分布式时代——SOA或者粒度更细的微服务。 当然随同而来的就是分库分表。 咱们可能会依据业务服务拆分的形式，对应地垂直拆分大库，例如原始大库拆分成订单库、商品库、领取库。同时因为业务数据可能会高速减少，很快就成了亿级，咱们不得不又程度分库，来加重单个数据库的压力。 不论是怎么分库的，最初的后果就是咱们一个操作可能要横跨多个数据库。 数据库自身的事务机制只能保障它本人这个库的事务，然而没法保障到其它的库。咱们要保障跨多个库的操作还具备事务的个性，就不得不上分布式事务了。 在后面 分布式必备实践根底：CAP和BASE 里，讲了分布式的实践根底——CAP和BASE，这里就不再多讲。 咱们只须要晓得，BASE实践是对CAP中AP的一个延申，在没法保障强一致性的前提下，尽可能达到最终的一致性。 咱们的分布式事务通常也做不到本地事务那么强的一致性，个别都是对一致性(Consistency)适当做了一些放宽，只须要达到最终的一致性。 分布式事务解决方案XA /2PC两阶段提交XAXA是一个分布式事务协定，由Tuxedo提出。 在这个协定里，有三个角色： AP（Application）：利用零碎（服务）TM（Transaction Manager）：事务管理器（全局事务管理）RM（Resource Manager）：资源管理器（数据库）XA标准次要定义了 事务管理器（Transaction Manager）和资源管理器（Resource Manager）之间的接口。 XA协定采纳两阶段提交形式来治理分布式事务。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。 2PC 两阶段提交两阶段提交的思路能够概括为： 参与者将操作成败告诉协调者，再由协调者依据所有参与者的反馈状况决定各参与者是否要提交操作还是停止操作。 两阶段提交的两个阶段：第一阶段：筹备阶段，第二阶段：提交阶段 ![两阶段-参考[2]](https://gitee.com/sanfene/pic...) 筹备阶段 Prepares 协调者向所有参与者询问是否能够执行提交操作，所有参与者执行事务，将后果返回给协调者。 提交阶段 commit 如果第一阶段汇中所有参与者都返回yes响应，协调者向所有参与者收回提交申请，所有参与者提交事务如果第一阶段中有一个或者多个参与者返回no响应，协调者向所有参与者收回回滚申请，所有参与者进行回滚操作 两阶段提交长处：尽量保障了数据的强统一，但不是100%统一 两阶段提交同样有一些毛病： 单点故障 因为协调者的重要性，一旦协调者产生故障，参与者会始终阻塞，尤其时在第二阶段，协调者产生故障，那么所有的参与者都处于锁定事务资源的状态中，而无奈持续实现事务操作。 同步阻塞 它是一个强一致性的同步阻塞协定，也就是所谓刚性事务，事务执⾏过程中须要将所需资源全副锁定，会比拟影响性能。 数据不统一 在第二阶段中，当协调者想参与者发送提交事务申请之后，因为网络抖动，如果第二阶段只有局部参与者收到提交申请，那么就会导致数据不统一。 3PC 三阶段提交三阶段提交（3PC）是二阶段提交（2PC）的一种改良版本 ，为解决两阶段提交协定的单点故障和同步阻塞问题。上边提到两阶段提交，当协调者解体时，参与者不能做出最初的抉择，就会始终放弃阻塞锁定资源。 2PC 中只有协调者有超时机制，3PC 在协调者和参与者中都引入了超时机制，协调者呈现故障后，参与者就不会始终阻塞。而且在第一阶段和第二阶段中又插入了一个预提交阶段，保障了在最初提交阶段之前各参加节点的状态是统一的。 ...

@[toc]网上对于分布式事务讲实践的多，讲实战的少，明天我想通过一个案例，来让小伙伴们感触一把分布式事务，咱们明天尽量少谈点实践。咱们明天的配角是 Seata！ 分布式事务波及到很多实践，如 CAP，BASE 等，很多小伙伴刚看到这些实践就被劝退了，所以咱们明天不讲实践，咱们就看个 Demo，通过代码疾速体验一把什么是分布式事务。 1. 什么是 Seata？Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简略易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。 Seata 反对的事务模式有四种别离是: Seata AT 模式Seata TCC 模式Seata Saga 模式Seata XA 模式Seata 中有三个外围概念： TC (Transaction Coordinator) - 事务协调者：保护全局和分支事务的状态，驱动全局事务提交或回滚。TM (Transaction Manager) - 事务管理器：定义全局事务的范畴，开始全局事务、提交或回滚全局事务。RM ( Resource Manager ) - 资源管理器：治理分支事务处理的资源( Resource )，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。其中，TC 为独自部署的 Server 服务端，TM 和 RM 为嵌入到利用中的 Client 客户端。 这些概念小伙伴们作为一个理解即可，不理解也能用 Seata，理解了更能了解 Seata 的工作原理。 2. 搭建 Seata 服务端咱们先来把 Seata 服务端搭建起来。 Seata 下载地址： https://github.com/seata/seata/releases目前最新版本是 1.4.2，咱们就应用最新版本来做。 这个工具在 Windows 或者 Linux 上部署差异不大，所以我这里就间接部署在 Windows 上了，不便一些。 ...

前言家喻户晓，分布式事务是个简单的问题，有很多种不同的思路和办法。 目前，只有是微服务架构做的分布式系统，就绕不开分布式事务这个话题。当然，并不是应用了分布式事务解决方案服务就稳固，高大上，不应用分布式事务服务也并不一定不好。目前咱们公司就没有应用分布式事务，一样撑起了稳固，灵便的零碎。分布式事务的抉择与否没有对错，在于实在我的项目中权衡利弊后的抉择。分布式事务倒退起源最开始咱们的利用是单体服务，在应用切当的状况下，spring的事务能够很好的帮咱们解决相干事务问题。简略剖析spring的事务：当某个代理办法应用 @Transactiona 并被AOP切面切到当前。spring会给aop切面中应用ThreadLocal治理同一个DBConnection。由这一个connection替咱们治理事务：即整个办法执行完结（活异样）则一起提交或者回滚事务。此时咱们的利用如下图： 或者这样 然而随着我的项目流量的增长，同一个DB连贯必定承接不住各类服务数据，因而，在理论的我的项目中，咱们大多数的利用与DB关系是这样的：咱们晓得，spring事务是在一个jvm下通过同一个db连贯管制的事务，然而当有多台服务器的时候，不同的服务器有本人的jvm，即便近程调用，db-connection必定不是同一个。由此，咱们须要一个第三者去协调每个服务的数据连贯。便产生了咱们常说的分布式事务问题。 筹备知识点ACID 原子性（Atomic）一致性（Consistency）隔离性（Isolation）持久性（Durability）隔离级别 Read Uncommitted(读未提交)Read Committed(读已提交)Repeated Read(反复读)Serialization(串行化)CAP定律 一致性（C） 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点拜访同一份最新的数据正本）可用性（A） 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写申请。（对数据更新具备高可用性）分区容错性（P） 以实际效果而言，分区相当于对通信的时限要求。零碎如果不能在时限内达成数据一致性，就意味着产生了分区的状况，必须就以后操作在C和A之间做出抉择。BASE实践BASE是Basically Available（根本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE实践是对CAP中一致性和可用性衡量的后果，其来源于对大规模互联网零碎分布式实际的总结， 是基于CAP定理逐渐演变而来的。BASE实践的核心思想是：即便无奈做到强一致性，但每个利用都能够依据本身业务特点，采纳适当的形式来使零碎达到最终一致性。根本可用 根本可用是指分布式系统在呈现不可预知故障的时候，容许损失局部可用性—-留神，这绝不等价于零碎不可用。比方：（1）响应工夫上的损失。失常状况下，一个在线搜索引擎须要在0.5秒之内返回给用户相应的查问后果，但因为呈现故障，查问后果的响应工夫减少了1~2秒（2）零碎性能上的损失：失常状况下，在一个电子商务网站上进行购物的时候，消费者简直可能顺利完成每一笔订单，然而在一些节日大促购物顶峰的时候，因为消费者的购物行为激增，为了爱护购物零碎的稳定性，局部消费者可能会被疏导到一个降级页面软状态 软状态指容许零碎中的数据存在中间状态，并认为该中间状态的存在不会影响零碎的整体可用性，即容许零碎在不同节点的数据正本之间进行数据同步的过程存在延时最终一致性 最终一致性强调的是所有的数据正本，在通过一段时间的同步之后，最终都可能达到一个统一的状态。因而，最终一致性的实质是须要零碎保障最终数据可能达到统一，而不须要实时保证系统数据的强一致性。开源的分布式事务框架目前世面上用于开源的分布式事务问题的框架还不少，比方seata,lcn,应用事务音讯rocketmq等等。而每种框架上面反对的模式又有很多种（能够想想为什么每种框架都反对好几种模式）。明天咱们具体解读一下seata的无代码侵入式的AT模式。 首先通过一个简略的sata例子认识一下 ============user模块=============/** * @author liuliang * @date 2021/7/9 2:31 下午 */@Slf4j@Servicepublic class UserService extends ServiceImpl<UserMapper, UserInfo> { @Resource private OrderFeign orderFeign; @GlobalTransactional public void buyProduct() { UserInfo userInfo = this.getById(1L); userInfo.setAmount(userInfo.getAmount() - 1); //扣减本人的余额 this.updateById(userInfo); //创立订单 orderFeign.test(); log.info("购买完结"); }}user模块调用order模块 /** * @author liuliang * @date 2021/7/9 2:58 下午 */@FeignClient(name = "mm-order")public interface OrderFeign { @GetMapping("/order/test") void test();}order模块 ...

Seata Server服务端搭建一、官网地址Seata 文档 Seata github Seata releases 二、Seata Server 下载这里地址为 1.3.0版本 seata-server-1.3.0 Linuxwget https://github.com/seata/seata/releases/download/v1.3.0/seata-server-1.3.0.zip三、批改配置文件配置文件次要有：registry.conf file.conf registry.conf : Seata 服务注册核心地址，配置核心地址file.conf : 当配置核心应用 file时，此配置文件失效。配置store存储配置 这里咱们应用eureka做为注册核心，Apollo做为配置核心 registry.confregistry { # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa type = "eureka" # 配置eureka地址 eureka { serviceUrl = "http://10.0.17.92:9001/eureka" application = "seata-server" weight = "1" } ... file { name = "file.conf" }}config { # file、nacos 、apollo、zk、consul、etcd3 #type = "file" type = "apollo" # 配置核心配置apollo地址和namespace apollo { appId = "seata-server" apolloMeta = "http://10.0.17.92:9083" namespace = "application" } file { name = "file.conf" }}file.conf## transaction log store, only used in seata-serverstore { ## store mode: file、db、redis mode = "db" ## file store property file { ## store location dir dir = "sessionStore" # branch session size , if exceeded first try compress lockkey, still exceeded throws exceptions maxBranchSessionSize = 16384 # globe session size , if exceeded throws exceptions maxGlobalSessionSize = 512 # file buffer size , if exceeded allocate new buffer fileWriteBufferCacheSize = 16384 # when recover batch read size sessionReloadReadSize = 100 # async, sync flushDiskMode = async } ## database store property db { ## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp)/HikariDataSource(hikari) etc. datasource = "druid" ## mysql/oracle/postgresql/h2/oceanbase etc. dbType = "mysql" driverClassName = "com.mysql.cj.jdbc.Driver" url = "jdbc:mysql://10.0.17.122:3306/seata" user = "root" password = "Pdhn^456" minConn = 5 maxConn = 30 globalTable = "global_table" branchTable = "branch_table" lockTable = "lock_table" queryLimit = 100 maxWait = 5000 } ## redis store property redis { host = "127.0.0.1" port = "6379" password = "" database = "0" minConn = 1 maxConn = 10 queryLimit = 100 }}Apollo配置Server配置次要批改：数据库地址 用户名 明码等 ...

分布式协调服务Zookeeper是分布式协调服务框架分布式协调技术: 次要用来解决分布式环境当中多个过程之间的同步控制,让过程有序的去拜访某种临界资源,避免造成"脏数据"的结果分布式协调技术的外围就是实现分布式锁 分布式锁分布式锁: 为了避免分布式系统中的多个过程之间互相烦扰,须要分布式协调技术对过程进行调度,这个分布式协调技术的外围就是实现分布式锁 分布式锁条件在分布式系统环境下,一个办法在同一时间只能被一个机器的一个线程执行高可用的获取锁与开释锁高性能的获取锁与开释锁具备可重入个性具备锁生效机制,避免死锁具备非阻塞锁个性 分布式锁的实现ZookeeperRedisMemcachedChubby Redis分布式锁的实现分布式锁实现的三个外围因素:加锁,解锁,锁超时Redis是单线程的 加锁应用setnx命令key是锁的惟一标识,按业务来决定命名value能够设置成任意值当一个线程执行setnx返回1,阐明key本来不存在,该线程胜利失去锁.当一个线程执行setnx返回0,阐明key曾经存在,该线程抢锁失败 解锁当失去锁的线程执行完工作,须要开释锁,以便其它线程能够进入,应用del指令开释锁之后,其它线程就能够继续执行setnx命令取得锁 锁超时一个失去所得线程在执行工作的过程中呈现问题,不能显式开释锁,这些资源将永远被锁住,造成死锁的状态setnx的key要设置一个超时工夫,保障锁没有被显式开释时,会在肯定工夫后主动开释.setnx不反对超时参数,须要额定的指令expireRedis分布式锁问题: 非原子性操作: 解决方案: 通过应用set命令set(key,value,expire) 设置为原子操作误删锁: 在设置锁超时的状况下,操作没有实现,当操作实现时,del命令删除的是其它过程的锁解决方案: 判断是否为本过程的锁.带着key和value=threadID线程ID判断是否为本过程的锁在设置锁超时的状况下,操作没有实现 解决方案: 开释锁时判断操作是否实现, 减少守护线程:为锁超时加时,提早开释

我的项目源码： https://gitee.com/benwang6/se... 一、订单业务案例1.1 创立 Empty Project：seata-at先新建文件夹 seata-samples，前面测试的 Seata AT 和 Seata TCC 模式都放在该目录下。 接着创立 seata-at 我的项目： 抉择 Empty Project： 填写我的项目名 seata-at 和寄存目录，寄存在你新建的 seata-samples 目录下： 1.2 数据库初始化工具订单案例波及四个数据库： 为了后续测试不便咱们编写一个工具，用来重置所有数据库表，能够不便地把数据重置到初始状态。 1.3 新建Module：db-init新建 Module，抉择 Spring Initializr 填写 Group 和 Artifact，其余选项默认即可： 增加 JDBC 和 MySQL Driver 依赖： 实现后，pom.xml 文件如下： <?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.3.2.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>cn.tedu</groupId> <artifactId>db-init</artifactId> <version>0.0.1-SNAPSHOT</version> <name>db-init</name> <description>Demo project for Spring Boot</description> <properties> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> <exclusions> <exclusion> <groupId>org.junit.vintage</groupId> <artifactId>junit-vintage-engine</artifactId> </exclusion> </exclusions> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build></project>1.4 application.yml 配置我的项目的 application.properties 文件改名成 application.yml，而后增加 mysql 连贯配置： ...

1. 前言本文先通过分布式事务中tcc计划，衍生出seata的tcc模式，次要还是会通过代码示例来做介绍。github代码地址可提前下载，该我的项目中包含数据库、seata配置，以及所有分布式服务的全副代码。大家如果想练练手，能够先拉取该我的项目代码，再联合本文学习。外围配置环境如下： 环境类型版本号jdk1.8.0_251mysql8.0.22seata server1.4.11.1. tcc咱们后面有几篇文章都有介绍过分布式事务的计划，目前常见的分布式事务计划有：2pc、tcc和异步确保型。之前讲过用jta atomikos实现多数据源的 2pc，用 异步确保型 计划实现领取业务的事务等等，就是没专门讲过 tcc 的利用。 因为tcc计划的操作难度还是比拟大的。不能单打独斗，最好须要依靠一个成熟的框架来实现。常见的tcc开源框架有tcc-transaction、Hmily和ByteTCC等，不过他们不像seata背靠大厂，无奈提供继续的保护，因而我更举荐seata的tcc计划。 1.2. seata先说说seata吧，分布式事务的解决方案必定不局限于下面说的三种，实际上形形色色。因为它确实很让人头疼，各位大神都想研发出最好用的框架。本文的配角 - seata ，就是阿里的一个开源我的项目。 seata提供了AT、TCC、SAGA 和 XA，一共4种事务模式。像AT模式就很受欢迎，咱们在实现多数据源的事务一致性时，通常会选用 2PC的计划，期待所有数据源的事务执行胜利，最初再一起提交事务。这个期待所有数据源事务执行的过程就比拟耗时，即影响性能，也不平安。 而seata AT模式的做法就很灵便，它学习数据库的 undo log，每个事务执行时立刻提交事务，但会把 undo 的回退sql记录下来。如果所有事务执行胜利，革除记录 undo sql的行记录，如果某个事务失败，则执行对应 undo sql 回滚数据。在保障事务的同时，并发量也大了起来。 但咱们明天要讲的是 seata TCC 模式，如果你对 Seata的其余模式感兴趣，能够上官网理解。 2. 业务先讲一下示例的业务吧，咱们还是拿比拟经典的电商领取场景举例。假如领取胜利后，波及到三个零碎事务： 订单零碎（order）：创立领取订单。库存零碎（storage）：对应商品扣除库存。账户零碎（account）：用户账户扣除响应金额。2.1. tcc业务依照tcc（try-confirm-cancel）的思路，这三个事务能够别离分解成上面的过程。 订单零碎 ordertry： 创立订单，然而订单状态设置一个长期状态（如：status=0）。confirm： try胜利，提交事务，将订单状态更新为齐全状态（如：status=1）。cancel： 回滚事务，删除该订单记录。库存零碎 storagetry： 将须要缩小的库存量解冻起来。confirm： try胜利，提交事务，应用解冻的库存扣除，实现业务数据处理。cancel： 回滚事务，解冻的库存冻结，复原以前的库存量。账户零碎 accounttry： 将须要扣除的钱解冻起来。confirm： try胜利，提交事务，应用解冻的钱扣除，实现业务数据处理。cancel： 回滚事务，解冻的钱冻结，复原以前的账户余额。2.2. 数据库为了模仿分布式事务，上述的不同零碎业务，咱们通过在不同数据库中创立表构造来模仿。当然tcc的分布式事务不局限于数据库层面，还包含http接口调用和rpc调用等，然而殊途同归，能够作为示例参考。 上面先列出三张业务表的表构造，具体的sql可见最初附件。 表：order列名类型备注idint主键order_novarchar订单号user_idint用户idproduct_idint产品idamountint数量moneydecimal金额statusint订单状态：0：创立中；1：已完结表：storage列名类型备注idint主键product_idint产品idresidueint残余库存frozenintTCC事务锁定的库存表：account列名类型备注idint主键user_idint用户idresidueint残余可用额度frozenintTCC事务锁定的金额3. seata server3.1. 下载seata server 的安装包可间接从官网github下载，下载压缩包后，解压到本地或服务器上。 3.2. 配置Seata Server 的配置文件有两个： seata/conf/registry.confseata/conf/file.confregistry.confSeata Server 要向注册核心进行注册，这样，其余服务就能够通过注册核心去发现 Seata Server，与 Seata Server 进行通信。Seata 反对多款注册核心服务：nacos 、eureka、redis、zk、consul、etcd3、sofa。咱们我的项目中要应用 eureka 注册核心，eureka服务的连贯地址、注册的服务名，这须要在 registry.conf 文件中对 registry 进行配置。 ...

博客原文分布式事务/零碎之底层原理揭秘 导言分布式事务是分布式系统必不可少的组成部分，基本上只有实现一个分布式系统就逃不开对分布式事务的反对。本文从分布式事务这个概念切入，尝试对分布式事务最外围的底层原理逐个进行分析，内容包含但不限于 BASE 准则、两阶段原子提交协定、三阶段原子提交协定、Paxos/Multi-Paxos 分布式共识算法的原理与证实、Raft 分布式共识算法和分布式事务的并发管制等内容。 事务事务是拜访并可能更新各种数据项的一个程序执行单元(unit)。事务由一个或多个步骤组成，个别应用形如 begin transaction 和 end transaction 语句或者函数调用作为事务界线，事务内的所有步骤必须作为一个繁多的、不可分割的单元去执行，因而事务的后果只有两种：1. 全副步骤都执行实现，2. 任一步骤执行失败则整个事务回滚。 事务最早由数据库管理系统(database management system，DBMS)引入并实现，数据库事务是数据库管理系统执行过程中的一个逻辑单位，由一个无限的数据库操作序列形成。数据库事务严格遵循 ACID 准则，属于刚性事务，一开始数据库事务仅限于对繁多数据库资源对象的访问控制，这一类事务称之为本地事务 (Local Transaction)，起初随着分布式系统的呈现，数据的存储也不可避免地走向了分布式，分布式事务（Distributed Transaction）便应运而生。 刚性事务 刚性事务（如繁多数据库事务）齐全遵循 ACID 标准，即数据库事务的四大根本个性： Atomicity（原子性）：一个事务（transaction）中的所有操作，或者全副实现，或者全副不实现，不会完结在两头某个环节。事务在执行过程中产生谬误，会被回滚（Rollback）到事务开始前的状态，就像这个事务素来没有执行过一样。即，事务不可分割、不可约简。Consistency（一致性）：在事务开始之前和事务完结当前，数据库的完整性没有被毁坏。这示意写入的材料必须完全符合所有的预设束缚、触发器、级联回滚等。Isolation（隔离性）：数据库容许多个并发事务同时对其数据进行读写和批改的能力，隔离性能够避免多个事务并发执行时因为穿插执行而导致数据的不统一。事务隔离分为不同级别，包含未提交读（Read uncommitted）、提交读（read committed）、可反复读（repeatable read）和串行化（Serializable）。Durability（持久性）：事务处理完结后，对数据的批改就是永恒的，即使系统故障也不会失落。刚性事务也可能以分布式 CAP 实践中的 CP 事务来作为定义。 柔性事务 在电商畛域等互联网场景下，传统的事务在数据库性能和解决能力上都遇到了瓶颈。因而，柔性事务被提了进去，柔性事务基于分布式 CAP 实践以及延长进去的 BASE 实践，相较于数据库事务这一类齐全遵循 ACID 的刚性事务来说，柔性事务保障的是 “根本可用，最终统一”，CAP 原理置信大家都很相熟了，这里咱们讲一下 BASE 准则： 根本可用（Basically Available）：零碎可能根本运行、始终提供服务。软状态（Soft-state）：零碎不要求始终放弃强统一状态。最终一致性（Eventual consistency）：零碎须要在某一时刻后达到一致性要求。柔性事务（如分布式事务）为了满足可用性、性能与降级服务的须要，升高一致性（Consistency）与隔离性（Isolation）的要求，遵循 BASE 实践，传统的 ACID 事务对隔离性的要求十分高，在事务执行过程中，必须将所有的资源对象锁定，因而对并发事务的执行极度不敌对，柔性事务（比方分布式事务）的理念则是将锁资源对象操作从本地资源对象层面上移至业务逻辑层面，再通过放宽对强一致性要求，以换取零碎吞吐量的晋升。 此外，尽管柔性事务遵循的是 BASE 实践，然而还须要遵循局部 ACID 标准： 原子性：严格遵循。一致性：事务实现后的一致性严格遵循；事务中的一致性可适当放宽。隔离性：并行事务间不可影响；事务两头后果可见性容许平安放宽。持久性：严格遵循。本地事务本地事务（Local Transaction）指的是仅仅对繁多节点/数据库资源对象进行拜访/更新的事务，在这种事务模式下，BASE 实践派不上用场，事务齐全遵循 ACID 标准，确保事务为刚性事务。 分布式事务在分布式架构成为支流的当下，系统对资源对象的访问不能还局限于单节点，多服务器、多节点的资源对象拜访成为刚需，因而，本地事务无奈满足分布式架构的零碎的要求，分布式事务应运而生。 拜访/更新由多个服务器治理的资源对象的立体事务或者嵌套事务称之为分布式事务（Distributed Transaction），分布式事务是绝对于本地事务来说的。 ...

Seata介绍Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简略易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。 2019 年 1 月，阿里巴巴中间件团队发动了开源我的项目 Fescar（Fast & EaSy Commit And Rollback），和社区一起共建开源分布式事务解决方案。Fescar 的愿景是让分布式事务的应用像本地事务的应用一样，简略和高效，并逐渐解决开发者们遇到的分布式事务方面的所有难题。 Fescar 开源后，蚂蚁金服退出 Fescar 社区参加共建，并在 Fescar 0.4.0 版本中奉献了 TCC 模式。 为了打造更中立、更凋谢、生态更加丰盛的分布式事务开源社区，通过社区核心成员的投票，大家决定对 Fescar 进行品牌降级，并更名为 Seata，意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。 Seata 交融了阿里巴巴和蚂蚁金服在分布式事务技术上的积攒，并积淀了新批发、云计算和新金融等场景下丰盛的实践经验，但要实现实用于所有的分布式事务场景的愿景，仍有很长的路要走。 Seata AT事务计划Seata 的 AT 模式（Automatic Transaction）是一种无侵入的分布式事务解决方案。上面联合具体业务场景来剖析其执行的原理。 业务场景订单零碎 当用户下订单时，执行以下三步流程： 订单零碎保留订单订单零碎调用库存服务，缩小商品库存订单零碎调用账户服务，扣减用户金额这三步要作为一个整体事务进行治理，要么整体胜利，要么整体失败。 Seata AT基本原理Seata AT 事务分两个阶段来治理全局事务：第一阶段： 执行各分支事务第二阶段： 管制全局事务最终提交或回滚 第一阶段：执行各分支事务微服务零碎中，各服务之间无奈互相感知事务是否执行胜利，这时就须要一个专门的服务，来协调各个服务的运行状态。这个服务称为 TC（Transaction Coordinator），事务协调器。 订单零碎开始执行保留订单之前，首先启动 TM（Transaction Manager，事务管理器），由 TM 向 TC 申请开启一个全局事务： 这时TC会产生一个全局事务ID，称为 XID，并将 XID 传回 TM： ...

数据库事务数据库事务由一组sql语句组成。 所有sql语句执行胜利则事务整体胜利；任一条sql语句失败则事务整体失败，数据恢复到事务之前的状态。 上面以转账为例进一步阐明。A 账户向 B 账户转账，须要更新两个账户的记录： - A 账户减金额update user set money=money-100 where id='A'- B 账户加金额update user set money=money+100 where id='B' 两条sql语句都胜利则转账胜利。任意一条sql语句失败，复原以前的状态。数据操作的最小单元是事务，而不是一条sql语句！ Mysql 事务操作开始事务start transaction;- 或begin; 事务开始后，对数据的增删改操作不间接批改数据表，而是被记录在日志文件中。 提交事务commit; 将日志中记录的操作，永恒保留到数据表，并清空日志文件。 回滚事务rollback;间接清空日志文件 事务个性 ACIDA - 原子性 Atomic一个事务是一个不可分割的工作单元，事务中包含的操作要么都做，要么都不做。 数据操作的最小单元是事务，而不是SQL语句 。 C - 一致性 Consistency事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。 例如： 转账前 a+b = 100转帐后 a+b = 100I - 隔离性 Isolation一个事务的执行不能被其余事务烦扰。 即一个事务外部的操作及应用的数据对并发的其余事务是隔离的，并发执行的各个事务之间不能相互烦扰。 D - 持久性 Durancy一个事务一旦提交，它对数据库中数据的扭转就应该是永久性的。接下来的其余操作或故障不应该对其有任何影响。 数据库并发拜访抵触问题脏读读取到其余事务未提交的数据。 不可反复读反复读取同一数据时，与之前读取的数据不统一。一个事务提交的数据，能够被另一个事务立刻读取。幻读读取到曾经被删除的数据。读取不到新插入的数据。Mysql 的四种事务隔离级别事务之间为了防止相互烦扰，执行时要进行隔离。也就是A执行时B要期待。但严格的隔离会造成性能的降落。 数据库为了兼顾数据安全和性能，能够在肯定水平上容许多个事务并行执行。 Mysql 提供了四种隔离级别从低到高： READ-UNCOMMITTEDREAD-COMMITTEDREPEATABLE-READSERIALIZABLE隔离级别越高数据越平安；越低性能越好，但会造成数据拜访的问题： 可能引发的问题READ-UNCOMMITTEDREAD-COMMITTEDREPEATABLE-READSERIALIZABLE幻读√√√×不可反复读√√××脏读√×××Mysql 设置隔离级别set tx_isolation='read-uncommitted';set tx_isolation='read-committed';# repeatable-read 是Mysql默认的隔离级别set tx_isolation='repeatable-read';set tx_isolation='serializable';oracle mysql 8 应用 transaction_isolation 零碎变量： ...

SagaSaga和TCC一样，也是最终一致性事务、柔性事务。Saga的实质就是把一个长事务分隔成一个个小的事务，每个事务都蕴含一个执行模块和弥补模块。Saga的模型如下： 每个Saga由一系列sub-transaction Ti 组成。每个Ti 都有对应的弥补动作Ci，弥补动作用于撤销Ti造成的后果。Saga的执行程序： T1, T2, T3, ..., TnT1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < nSaga的复原形式： 向后复原：撤销Ti造成的后果。向前复原：始终重试Tj前面的事务，直至胜利，这个时候须要保障肯定胜利。然而其实很难保障的，比方扣减库存，曾经库存为0了，你让他怎么减。所以失常用向后复原。同样用TCC的例子来阐明一下。失常状况下，订单服务把状态改为已出库，提交事务后，调用库存服务，更改库存值。如果库存服务出现异常，向后复原的话，就是把已出库的状态改为未出库。向前复原的话，就是始终调用库存服务，直至库存扣减胜利。 和TCC比照Saga没有try，间接提交事务，所以也没有预留资源。比方库存，TCC会解冻掉，Saga是间接扣除。从通信上来说，Saga通信次数少，等于子事务的个数，而TCC是子事务的2倍（try后再commit一次）。从业务上来说，TCC的侵入性更大，每个业务流程都要Try、Commit、Cancel。Saga只有提供一个中央对事务弥补就好了。

TCC分布式事务，分为三个阶段，Try（尝试）-Confirm（确认）-Cancel（勾销），他的实质就是预留资源，比方对状态的变更，对金额的解冻，上面通过一个出库的例子来阐明。仓库人员清单完货品，确认出库，此时零碎须要两个操作，一个是库存订单状态从未出库更改为已出库，另外一个是库存的扣减。 trytry的时候就是对资源的预留，比方订单，就要把状态从未出库改为待出库，库存比方是100，此时要加一个解冻库存字段，解冻值为此次的出库数量，假如10，理论库存变成了100-10=90。try的时候间接在数据库做变更，当然咱们并不是间接的变更值，而是先做判断。比方状态是待出库或者已出库，则此时就不能更改。比方库存此时有余10，扣减失败。 Confirm如果合乎出库和库存扣减条件，则确认业务，把待出库的状态改已出库，把库存改为90，解冻为0。 Cancel如果某个条件不满足或者都不满足，则勾销业务，把待出库的状态改为未出库，把库存改为100，解冻为0。也就是说把资源复原到之前的状态。 和2PC区别TCC对业务的侵入性很大，每个子业务都要写Try-Confirm-Cancel，。2PC是在数据库层面上管制的，对开发者是无感知的。2PC是强一致性事务，TCC是最终一致性事务（当然有可能订单服务是try执行胜利，库存服务的try执行失败，这个时候要保障多个零碎的可用性）。TCC每个阶段都是本地提交事务，而2PC会始终锁住资源直至整个过程完结，所以TCC的性能更高，有更高的吞吐量。

Distributed Transaction Processing: Reference Model Distributed Transaction Processing: The XA Specification 1、事务简介        事务(Transaction)是拜访并可能更新数据库中各种数据项的一个程序执行单元(unit)。在关系数据库中，一个事务由一组SQL语句组成。事务应该具备4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID个性。     原子性（atomicity）：个事务是一个不可分割的工作单位，事务中包含的诸操作要么都做，要么都不做。     一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态，事务的中间状态不能被察看到的。     隔离性（isolation）：一个事务的执行不能被其余事务烦扰。即一个事务外部的操作及应用的数据对并发的其余事务是隔离的，并发执行的各个事务之间不能相互烦扰。隔离性又分为四个级别：读未提交(read uncommitted)、读已提交(read committed，解决脏读)、可反复读(repeatable read，解决虚读)、串行化(serializable，解决幻读)。     持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的扭转就应该是永久性的。接下来的其余操作或故障不应该对其有任何影响。     任何事务机制在实现时，都应该思考事务的ACID个性，包含：本地事务、分布式事务。 2 本地事务        大多数场景下，咱们的利用都只须要操作繁多的数据库，这种状况下的事务称之为本地事务(Local Transaction)。本地事务的ACID个性是数据库间接提供反对。本地事务利用架构如下所示：     在JDBC编程中，咱们通过java.sql.Connection对象来开启、敞开或者提交事务。代码如下所示： 代码块 Plain Text Connection conn = ... //获取数据库连贯 conn.setAutoCommit(false); //开启事务 try{ //...执行增删改查sql conn.commit(); //提交事务 }catch (Exception e) { conn.rollback();//事务回滚 }finally{ conn.close();//敞开链接 }    此外，很多java利用都整合了spring，并应用其申明式事务管理性能来实现事务性能。个别应用的步骤如下：     1、配置事务管理器。spring提供了一个PlatformTransactionManager接口，其有2个重要的实现类：         DataSourceTransactionManager：用于反对本地事务，事实上，其外部也是通过操作java.sql.Connection来开启、提交和回滚事务。 ...