分布式事务

本文转自： https://baijiahao.baidu.com/s?id=1627688882923429891&wfr=spider&for=pc 当一张表的数据达到几千万时，查询一次所花的时间会变长。这时候，如果有联合查询的话，可能会卡死在那儿，甚至把系统给拖垮。 而分库分表的目的就在于此：减小数据库的负担，提高数据库的效率，缩短查询时间。另外，因为分库分表这种改造是可控的，底层还是基于RDBMS，因此整个数据库的运维体系以及相关基础设施都是可重用的。 目前我们系统将近20亿数据，每张表最大的接近600w条/表，每条数据大约3k，每个表将近1.5G的数据。查询经常超时，单条SQL执行count(*)查询时间达到了最大260ms，0.26s（标准是超过0.1s的数据为慢SQL）。 为了说明我们为什么要分库分表，我们看一下sql的执行过程。 mysql执行一条sql的过程如下： 1、收到sql 2、把sql放到排队队列中 3、执行sql 4、返回结果 在这个执行过程中最花时间的地方在于： 1.排队等待的时间， 2.sql的执行时间。 如果有2个sql都要同时修改同一张表的同一条数据，mysql对这种情况的处理是：一种是表锁定（MyISAM存储引擎），一个是行锁定（InnoDB存储引擎）。 表锁定表示其他操作都不能对这张表进行操作，必须等当前对表的操作完才行。行锁定也一样

现在先抛出问题，假设有一个主数据中心在北京M，然后有成都A，上海B两个地方数据中心，现在的问题是，假设成都上海各自的数据中心有记录变更，需要先同步到主数据中心，主数据中心更新完成之后，在把最新的数据分发到上海，成都的地方数据中心A，地方数据中心更新数据，保持和主数据中心一致性（数据库结构完全一致）。数据更新的消息是通过一台中心的MQ进行转发。 先把问题简单化处理，假设A增加一条记录Message_A，发送到M，B增加一条记录 MESSAGE_B发送到M，都是通过MQ服务器进行转发，那么M系统接收到条消息，增加两条数据，那么M在把增加的消息群发给A，B，A和B找到自己缺失的数据，更新数据库。这样就完成了一个数据的同步。 从正常情况下来看，都没有问题，逻辑完全合理，但是请考虑以下三个问题 1 如何保证A->M的消息，M一定接收到了，同样，如何保证M->A的消息，M一定接收到了 2 如果数据需要一致性更新，比如A发送了三条消息给M，M要么全部保存，要么全部不保存，不能够只保存其中的几条记录。我们假设更新的数据是一条条发送的。 3 假设同时A发送了多条更新请求，如何保证顺序性要求？ 这两个问题就是分布式环境下数据一致性的问题 对于第一个问题，比较好解决，我们先看看一个tcp/ip协议链接建立的过程 我们的思路可以从这个上面出发，在简化一下，就一个请求，一个应答。 简单的通信模型是这样的 A

摘要： 前言目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总... 前言 目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总结了几个点，更多的应用系统在编码的时候，更加关注数据的一致性，这样系统才是健壮的。 基础理论相关 说起事务，目前的几个理论，ACID事务特性，CAP分布式理论，以及BASE等，ACID在数据库事务中体现，CAP和BASE则是分布式事务的理论，结合业务系统，例如订单管理，例如仓储管理等，可以借鉴这些理论，从而解决问题。 ACID 特性 A（原子性）事务的原子操作单元，对数据的修改，要么全部执行，要么全部不执行； C（一致性）在事务开始和完成时，数据必须保持一致状态，相关的数据规则必须应用于事务的修改，以保证数据的完整性，事务结束时，所有的内部数据结构必须正确； I（隔离性

#1 前言 系列目录 分布式事务系列（开篇）提出疑问和研究过程 分布式事务系列（1.1）Spring事务管理器PlatformTransactionManager源码分析 分布式事务系列（1.2）Spring事务体系 分布式事务系列（2.1）分布式事务模型与接口定义 分布式事务系列（3.1）jotm的分布式案例 分布式事务系列（3.2）jotm分布式事务源码分析 分布式事务系列（4.1）Atomikos的分布式案例 对于我们这种初学者，可能会使用spring带给我们的@Transactional，可能了解JTA，可能会使用jotm、atomikos，又会遇到一些名词XA，支持XA的数据库驱动等等诸多问题，然后就会愈加混乱，自然形成一个疑问，庞大的事务体系的全貌到底是什么样？ #2 需要解决的疑惑 下面就要具体列出一系列需要解决的问题 ##2.1 对于事务模型 三种事务模型是什么？各自的特点是什么？各自的缺陷是什么？ ##2.2 spring对于事务模型的支持 spring自己的一系列接口设计： PlatformTransactionManager 事务管理器 TransactionDefinition 事务定义 TransactionStatus 事务状态 等等 上述一系列接口的实现是如何对非分布式和分布式事务的支持的呢？ ##2.3 针对分布式事务的规范 X/Open

一、分布式锁 　　分布式锁是在分布式场景下一种常见技术，通常通过基于redis和zookeeper来实现，本文主要介绍redis分布式锁和zookeeper分布式锁的实现方案和对比： 　　（1）基于redis的普通实现 　　这个方案的加锁主要实现是基于redis的”SET key 随机值 NX PX 过期时间（毫秒）”指令，NX代表只有key不存在时才设置成功，PX代表在过期时间后会自动释放。 　　这个方案的释放锁是通过lua脚本删除key的方式，判断value一样则删除key。 　　使用随机值的原因是如果某个获取到锁的客户端阻塞了很长时间，导致了它获取到的锁已经自动释放，此时可能有其他客户端已经获取到了锁，如果直接删除是有问题的，所以要通过随机值加上lua脚本去判断如果value相等时再删除。 　　这个方案存在一个问题就是，如果采用redis单实例可能会存在单点故障问题，但如果采用普通主从方式，如果主节点挂了key还没来得及同步到从节点，此时从节点被切换到了主节点，由于没有同步到数据别人就会拿到锁。 　　（2）redis的RedLock算法 　　这个方案是redis官方推荐的分布式锁的解决方案，假设有5个redis master实例，然后执行如下步骤去获取一把锁： 　　1）获取当前时间戳，单位是毫秒 　　2）跟上面类似，轮流尝试在每个master节点上创建锁，过期时间较短

参考网址： https://www.txlcn.org/en-us/docs/demo/dubbo.html 目的：用户多个模块之间的事务的管理，保持数据的一致性 联通实验室测试 1.启动redis 192.168.100.2服务器上面的 /usr/local/ 2.启动 txlcn-tm 192.168.100.2服务器，端口 http://192.168.100.2:7970 密码codingapi 注意： 1.打包命令：mvn clean package -Dmaven.test.skip=true 2.j ar报没有main函数，pom.xml加上 <!-- 解决 SpringBoot 打包成 jar 后运行提示没有主清单属性 --> < plugin > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-maven-plugin </ artifactId > < executions > < execution > < goals > < goal > repackage </ goal > </ goals > </ execution > </ executions > < configuration > < mainClass > com.codingapi

　　为了解决分布式一致性问题，产生了不少经典的分布式一致性算法，本文将介绍其中的2PC和3PC。2PC即Two-Phase Commit，译为二阶段提交协议。3PC即Three-Phase Commit，译为三阶段提交协议。 分布式系统和分布式一致性问题 　　分布式系统，即运行在多台不同的网络计算机上的软硬件系统，并且仅通过消息传递来进行通信和协调。 　　分布式一致性问题，即相互独立的节点之间如何就一项决议达成一致的问题。 2PC 　　2PC，二阶段提交协议，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者。 　　 阶段1：准备阶段 　　1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。 　　2、各参与者执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。 　　3、如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。 　　 阶段2：提交阶段 　　此阶段分两种情况：所有参与者均反馈YES、或任何一个参与者反馈NO。 　　所有参与者均反馈YES时，即提交事务。 　　任何一个参与者反馈NO时，即中断事务。 　　提交事务：（所有参与者均反馈YES） 　　1、协调者向所有参与者发出正式提交事务的请求（即Commit请求）。 　　2

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在这几年越来越火的微服务架构中，几乎可以说是无法避免。 本篇文章将通过详解分布式事务的一致性，以及分布式事务实战解决方案，帮助大家搞懂分布式事务，推荐收藏。 01 为什么需要分布式事务 由于近十年互联网的发展非常迅速，很多网站的访问越来越大，集中式环境已经不能满足业务的需要了，只能按照业务为单位进行数据拆分(包含：垂直拆分与水平拆分)，以及按照业务为单位提供服务，从早期的集中式转变为面向服务架构的分布式应用环境。 举一个典型的例子，阿里的淘宝网站随着访问量越来越大，只能按照商品、订单、用户、店铺等业务为单位进行数据库拆分，以及按照业务为单位提供服务接口。 这个时候 为了完成一个简单的业务功能，比如：购买商品后扣款，有可能需要横跨多个服务，涉及用户订单、商品库存、支付等多个数据库，而这些操作又需要在同一个事务中完，这就涉及到到了分布式事务。 本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。 02 分布式的一致性理论 最早加州大学伯克利分校 Eric Brewer教授提出一个分布式系统特性的CAP理论。 1.CAP 理论的不可能三角 一致性（Consistency） 可用性（Availability） 分区容错性（Partition tolerance） 在分布式系统中

摘要说明： 简单的说 事务 的本质就是将多个非原子性的操作构造成一个“原子性”的执行单元的机制；即多个原子操作要么全部成功，要么全部失败即 回滚 ； 但往往一个业务会因为多种原因需要划分成多个这样的节点，通常的原因有 业务划分产生多个节点如微服务； 由于多个数据源产生多个节点； 简单的说分布式事务需要保证这些小节点要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库或操作的数据一致性。 一、什么是分布式事务？ 事务 提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 那什么是 分布式事务 ？ 举个例子，微服务中有两个服务分别是服务A和服务B，若服务A的一个接口a调用服务B的接口B成功后处理自己的逻辑时出现异常，那么服务A回滚本身接口a的业务的同时，如何协调服务B将其接口b的业务回滚；这就是 分布式事务 ； 分布式事务 就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用

正文 我们先套一个业务场景进去，如下图所示 那页面点了支付按钮，调用支付服务，那我们后台要实现下面三个步骤 [1] 订单服务-修改订单状态 [2] 账户服务-扣减金钱 [3] 库存服务-扣减库存 达到事务的效果，要么一起成功，要么一起失败！就要采取TCC分布式事务方案！ 概念 TCC的全称是（Try-Confirm-Cancel）。如下图所示 ps:TCC又可以被称为两阶段补偿事务，第一阶段try只是预留资源，第二阶段要明确的告诉服务提供者，这个资源你到底要不要，对应第二阶段的confirm/cancel，用来清除第一阶段的影响，所以叫补偿型事务。 再打个比方，说TCC太高大上是吧，讲RM中的prepare、commit、rollback接口，总知道吧。可以类比的这么理解 那差别在哪呢? rollback、commit、prepare，站在开发者层面是感知不到的，数据库帮你做了资源的操作! 而try、confirm、cancel，站在开发者层面是能感知到的，这三个方法的业务逻辑，即对资源的操作，开发者是要自己去实现的！ 好，下面套入我们的场景，怎么做呢。比如，你的订单服务中本来只有一个接口 //修改代码状态 orderClient.updateStatus()； 都要拆为三个接口，即 orderClient.tryUpateStatus()； orderClient