分布式事务

自建商城在设计之初，业务部门就提出了两个要求： 不崩 & 快速上线。 在立项之后，团队还没有完全配备好，一边从其他团队里调取人手，一边大力招聘，与此同时，我们的架构师也在搭建一套分布式商城开发框架，编写 Demo，让新加入的同学能快速上手。 暴露问题 问题一： 分布式事务 为什么会使用分布式事务？ 这个暂且可以归因于快速上线，因为生成订单会调用到商品服务扣减库存，使用了分布式事务解决了因为跨服务调用引起库存超卖的问题，带来的问题就是性能上的消耗。 问题二： 数据库压力 在大促活动期间，有个实时统计是直接从业务库上直接查询统计的，运营部门的小姐姐在不断地刷新，导致该接口上的压力山大，而且没有使用缓存，连 SQL 查询条件的时间都是动态的，导致 DB 层的缓存也使用不上，每次请求都打到 DB 上。 开发和测试环境是使用自建的 MySQL，生产环境使用的是 PolarDB，从阿里云官网上看到： 集群架构，计算与存储分离 读写分离 我们主观地认为，只要我们使用了集群连接地址就会自动进行读写分离，但是实际上并没有，后来发现在方法上显式的指定只读事务就有请求走到只读节点上了。 @Transactional(readOnly = true) # 优化思路： 1）从 SQL 洞察和慢 SQL 里找调用响应时间最长和频度最高的 SQL； 2）结合代码，能用缓存代替的直接处理掉，不用能缓存的优化查询

大纲 1.什么是事务？ 2.事务的四大特性ACID 3.数据库的四种隔离级别 4.事务并发执行会出现的问题 1.什么是事务（Transaction）？ 　　一组操作，要么全部执行成功，要么全部不执行。事务由一组操作组成，其中任一操作发生错误，则回滚之前成功的操作。 2.数据库事务的四大特性ACID 　　 原子性（Atomicity） ：事务是一个不可分割的执行单元，事务包含的全部操作要么全部执行成功，要么全部失败回滚。也即成功则完全应用到数据库，失败则对数据库不产生任何变更。 　　 一致性（Consistency） ：事务开始前和结束后， 数据库的完整性约束（存储在数据库中的所有值都是正确的） 没被破坏。 　　 隔离性（Isolation） ：每个事务相互独立，互不干扰，一个事务无法看到另一个事务中的数据。 　　 持久性（Durability） ：事务执行完成，其结果是持久化保存的。即使数据库发生崩溃，数据库恢复后事务提交的结果仍然存在（当然如果数据无法恢复的另说）。 3.数据库的四种隔离级别 　　 Serializable (串行化)： 可避免脏读、不可重复读、幻读的发生。 　　 Repeatable read (可重复读)： 可避免脏读、不可重复读的发生。 　　 Read committed (读已提交)： 可避免脏读的发生。 　　 Read uncommitted (读未提交

1. 分布式事务原理解析 1.1. TCC分布式事务 了解过TCC分布式事务的都知道它有三个阶段：try，confirm，cancel，但很多文章就只有原理图，和对原理图的解释，看一遍也留不下印象，这里用实际场景举个例子，说明TCC分布式事务原理 try阶段：假设我们又订单系统，它需要调用库存和积分系统，try阶段我们进行的是 预处理 ，比如下单1个商品，在try操作中，我们在库存表设置个冻结字段，表示冻结1个商品，商品的存量先不扣除，而积分表同样添加个预增加积分字段，添加个预积分比如10 confirm阶段： 我们为什么要经历try阶段？ ，为了尽可能的保证各个系统都是正常工作的，数据库，服务都没有挂掉，资源没有不足，则可以最大程度上保证confirm阶段能正确执行， confirm阶段也就是正式的扣除库存和增加积分 cancel阶段： 若try阶段执行错误 ，则会对前面已经执行的try阶段的系统执行cancel操作，也就是反向SQL回滚，冻结的商品-1，预积分-10。到这里有没有疑问？我首先想到的是 若confirm或cancel操作再执行失败怎么办 ？这里就要由TCC分布式事务框架保证了，它会 记录事务活动日志 ，再confirm或cancel失败后不断尝试调用confirm和cancel的逻辑，所以这里需要开发者自己保证，你的SQL是正确的 TCC分布式框架推荐

什么场景下会产生分布式事务？ 在支付异步回调的情况下，支付宝发送http请求给第三方平台，第三方平台需要更改支付状态以及订单状态，在此场景下，第三方平台更改本地支付数据库的支付状态后，通知订单服务更改订单的状态，在此程序后，如果代码出现异常，由于有声明式事务的存在，本地支付服务的数据库会进行回滚，变成未支付状态，但是订单服务的状态却无法回滚，订单服务的订单的状态变成已支付状态，这就出现了订单数据库和支付数据库数据不一致的情况，这便是分布式事务产生的场景之一。 什么是分布式事务？ 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 分布式事务的理论 1、cap理论 1）数据一致性（consistency） 如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency) 一致性指

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、微服务以及分布式数据管理中存在的问题 单体应用通常使用单个关系型数据库，由此带来的好处在于应用能够使用 ACID 事务，后者提供了重要的操作特性： 原子化： 原子粒度的更改 一致性： 数据库的状态始终保持一致 隔离： 并发执行的事务显示为串行执行 持久： 事务一旦提交就不会被撤销 如此，应用能够简单地开始事务、更改（插入、更新和删除）多行、以及提交事务。 使用关系型数据库的另一大好处是它支持 SQL。SQL 是一门丰富、可声明的和标准化的查询预约。用户能够轻松通过查询将多个表中的数据组合起来，然后 RDBMS 查询调度器决定执行查询的最优方法。用户不必关心底层细节，比如如何访问数据库。此外，由于所有的应用数据在一个数据库中，很容易查询。 然而，微服务架构中的数据访问变得复杂许多。每个微服务拥有的数据专门用于该微服务，仅通过其 API 访问。这种数据封装保证了微服务松散耦合，并且可以独立更新。但如果多个服务访问相同数据，架构更新会耗费时间、也需要所有服务的协调更新。 更糟糕的是，不同的微服务通常使用不同类型的数据库。现代应用存储和处理各种类型的数据，而关系型数据库并非总是好选择。对于一些使用场景，特定的 NoSQL 数据库能提供更方便的数据模型、更好的性能和可扩展性。譬如，服务使用 Elasticsearch

分布式事务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 直接执行资源操作，（如

在 关于分布式事务的理解 一文中，最后留了一个坑是关于TCC框架的。当时由于时间问题耽搁了，最近总算有时间把这个坑填上了。 本文会大致介绍下两阶段和三阶段提交，以及TCC模式。 分布式事务分为 两阶段型 补偿型 异步确保型 最大努力通知型几种 上文我们已近介绍了 异步确保型 和 最大努力通知 这两种服务模式的具体应用，接下来介绍下剩下两种。 两阶段提交（2PC）型 两阶段型：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。 准备阶段 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。 可以进一步将准备阶段分为以下三个步骤： 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。 （注意：若成功这里其实每个参与者已经执行了事务操作） 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功， 则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。 提交阶段 如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚

一、前言 　　 在大数据系统中，分布式系统已经成为一个无法避免的组件，如zookeeper已经成为了工业届的标准。所以对于大数据的研究，也必须要研究分布式系统的特点。 二、集中式系统 　　由一台或多台计算机组成的中心节点，数据集中存储在这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。其部署简单，不用考虑多个节点间的分布式协作问题。 三、分布式系统 　　分布式系统是一个由硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。其拥有如下特点 　　 3.1 分布性 　　分布式系统中的多台计算机都会在空间中随意分布，同时，机器的分布情况也会随时变动。 　 　3.2 对等性 　　分布式系统中的计算机没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的， 副本 指的是分布式系统对数据和服务提供的一种冗余方式，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。 数据副本 是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。 服务副本 是只多个节点提供同样的服务，每个节点都有能力接受来自外部的请求并进行相应的处理。 　 　3.3 并发性 　　同一分布式系统中的多个节点

TX-LCN的3种模式 LCN5.0.2有3种模式，分别是LCN模式，TCC模式，TXC模式 LCN模式： LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。 该模式的特点： - 该模式对代码的嵌入性为低。 - 该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。 - 该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。 - 该模式缺陷在于代理的连接需要随事务发起方一共释放连接，增加了连接占用的时间。 TCC模式： TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。 该模式的特点： - 该模式对代码的嵌入性高，要求每个业务需要写三种步骤的操作。 - 该模式对有无本地事务控制都可以支持使用面广。 - 数据一致性控制几乎完全由开发者控制，对业务开发难度要求高。 TXC模式： TXC模式命名来源于淘宝，实现原理是在执行SQL之前，先查询SQL的影响数据

分布式事务之解决方案（XA和2PC） https://zhuanlan.zhihu.com/p/93459200 ​ 博彦信息技术有限公司 java工程师 3. 分布式事务解决方案之2PC（两阶段提交） 针对不同的分布式场景业界常见的解决方案有2PC、TCC、可靠消息最终一致性、最大努力通知这几种。 3.1. 什么是2PC 2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两阶段，P是指准备阶段，C是提交阶段。 举例 ：张三和李四好久不见，老友约起聚餐，饭店老板要求先买单，才能出票。这时张三和李四分别抱怨近况不如意，囊肿羞涩，都不愿意请客，这时只能AA。只有张三和李四都付款，老板才能出票安排就餐。但由于张三和李四都是铁公鸡，形成两尴尬的一幕 ： 准备阶段 ：老板要求张三付款，张三付款。老板要求李四付款，李四付款。 提交阶段 ：老板出票，两人拿票纷纷落座就餐。 例子中形成两一个事务，若张三或李四其中一个拒绝付款，或钱不够，店老板都不会给出票，并且会把已收款退回。 整个事务过程由事务管理器和参与者组成，店老板就是事务管理器，张三、李四就是事务参与者，事务管理器负责决策整个分布式事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚。 在计算机中部分关系数据库如Oracle