分布式事务

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分布式框架推荐

现在很火的微服务系统所设计的系统是分布式系统。分布式系统有一个著名的CAP理论，即一个分布式系统要同时满足一致性（Consistency）、可用性（Availablility）和分区容错（Partition Tolerance）三个特性是一件不可能的事情。 CAP理论的简介 CAP理论是由Eric Brewer在2000年的PODC会议上提出的，该理论在两年后被证明成立。 CAP理论告诉架构师不要妄想设计出同时满足三者的系统，应该有所取舍，设计出适合业务的系统。 一致性（Consistency）： 一致性指的是数据的强一致性。每次的读操作都是读取的最新数据。即如果写入某个数据成功的话，之后的读取都应该读的是新写入的数据；如果写入失败的话，之后读取的都不应该是写入失败的数据。 可用性（Availability）： 可用性指的是服务的可用性。即每个请求都能在合理的时间内获得符合预期的响应结果。 分区容错性（Partition Tolerance）： 分区容错性指的是当节点之间的网络出现问题之后，系统仍然能够正常提供服务。 在分布式的系统中，P是基本要求，而单体应用则是CA系统。微服务系统通常是一个AP系统，即同时满足可用性和分区容错性。这样就有了一个在分布式系统中保证数据强一致性的难题，这个难题的一个解决方案就是分布式事务。 分布式事务的解决方案 在微服务系统中

分布式场景常见问题及解决方案 前言: 本文主要是根据平常学习过程中遇到的一些分布式场景常见问题，并作出了解析，有不对或者需要补充的地方，希望广大的程序员朋友们及时改进，另外，想要学习，分布式的朋友，我提供一张分布式的学习路线思维导图，望可以给你们一点建议。 下面进入正题 一、分布式锁 分布式锁是在分布式场景下一种常见技术，通常通过基于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算法

#1 系列目录 分布式事务系列（开篇）提出疑问和研究过程 分布式事务系列（1.1）Spring事务管理器PlatformTransactionManager源码分析 分布式事务系列（1.2）Spring事务体系 分布式事务系列（2.1）分布式事务模型与接口定义 分布式事务系列（3.1）jotm的分布式案例 分布式事务系列（3.2）jotm分布式事务源码分析 分布式事务系列（4.1）Atomikos的分布式案例 #2 与Spring集成方式使用jotm 工程代码地址： 与Spring集成方式使用jotm 先来感受下一个分布式事务的案例（使用一般的数据库驱动，不需要支持分布式XA协议）： ##2.1 业务逻辑的操作 UserDao和LogDao,操作分别如下： @Repository public class UserDao { @Resource(name="jdbcTemplateA") private JdbcTemplate jdbcTemplate; public void save(User user){ jdbcTemplate.update("insert into user(name,age) values(?,?)",user.getName(),user.getAge()); } } @Repository public class LogDao {

#1 系列目录 分布式事务系列（开篇）提出疑问和研究过程 分布式事务系列（1.1）Spring事务管理器PlatformTransactionManager源码分析 分布式事务系列（1.2）Spring事务体系 分布式事务系列（2.1）分布式事务模型与接口定义 分布式事务系列（3.1）jotm的分布式案例 分布式事务系列（3.2）jotm分布式事务源码分析 分布式事务系列（4.1）Atomikos的分布式案例 #2 Atomikos使用非XA数据库驱动实现分布式事务 项目地址见： Atomikos使用非XA数据库驱动实现分布式事务 ##2.1 业务逻辑的操作 UserDao和LogDao,操作分别如下： @Repository public class UserDao { @Resource(name="jdbcTemplateA") private JdbcTemplate jdbcTemplate; public void save(User user){ jdbcTemplate.update("insert into user(name,age) values(?,?)",user.getName(),user.getAge()); } } @Repository public class LogDao { @Resource(name="jdbcTemplateB")

#0 系列目录# 分布式事务 【分布式事务系列】提出疑问和研究过程 对于我们这种初学者，可能会使用Spring带给我们的@Transactional，可能了解JTA，可能会使用jotm、atomikos，又会遇到一些名词XA，支持XA的数据库驱动等等诸多问题，然后就会愈加混乱，自然形成一个疑问，庞大的事务体系的全貌到底是什么样？ #1 需要解决的疑惑# 下面就要具体列出一系列需要解决的问题。 ##1.1 对于事务模型## 三种事务模型是什么？各自的特点是什么？各自的缺陷是什么？ ##1.2 Spring对于事务模型的支持## Spring自己的一系列接口设计： PlatformTransactionManager 事务管理器 TransactionDefinition 事务定义 TransactionStatus 事务状态 等等 上述一系列接口的实现是如何对非分布式和分布式事务的支持的呢？ ##1.3 针对分布式事务的规范## X/Open DTP模型是什么？几个重要的概念是什么？ XA规范是什么？ 2PC是什么？ ##1.4 针对JTA## JTA是什么？JTS又是什么？ JTA与上述的规范又是什么关系？ JTA的接口都有哪些？分别是什么作用 JTA接口中有一个javax.transaction.TransactionManager

分布式设计与开发 CAP原理和最终一致性(Eventually Consistency) 分布式算法 [分布式Paxos算法] 分布式一致性Hash算法 轮循算法（Round Robin） Hash求余算法（Hash） 最少连接算法（Least Connection） 响应速度算法（Response Time） 加权算法（Weighted） 分布式消息 分布式发布订阅消息系统Kafka架构设计 分布式缓存 Redis 分布式 Memcached 分布式 分布式存储 分布式事务 【分布式事务系列一】提出疑问和研究过程 【分布式事务系列二】Spring事务管理器PlatformTransactionManager 【分布式事务系列三】Spring的事务体系 【分布式事务系列四】分布式事务的概念 【分布式事务系列五】jotm的分布式案例 【分布式事务系列六】jotm分布式事务源码分析 【分布式事务系列七】Atomikos的分布式案例 【分布式事务系列八】JTA深度历险-原理与实现 【分布式事务系列九】聊聊分布式事务 来源： oschina 链接： https://my.oschina.net/u/120166/blog/540071

在OLTP 系统领域，我们在很多业务场景下都会面临事务一致性方面的需求，例如最经 典的Bob 给Smith 转账的案例。传统的企业开发，系统往往是以单体应用形式存在的，也 没有横跨多个数据库。 我们通常只需借助开发平台中特有数据访问技术和框架（例如Spring、JDBC、 ADO.NET），结合关系型数据库自带的事务管理机制来实现事务性的需求。关系型数据库 通常具有ACID 特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、 持久性（Durability）。 我们通常只需借助开发平台中特有数据访问技术和框架（例如Spring、JDBC、 ADO.NET），结合关系型数据库自带的事务管理机制来实现事务性的需求。关系型数据库 通常具有ACID 特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、 持久性（Durability）。 而大型互联网平台往往是由一系列分布式系统构成的，开发语言平台和技术栈也相对比 较杂，尤其是在SOA 和微服务架构盛行的今天，一个看起来简单的功能，内部可能需要调 用多个“服务”并操作多个数据库或分片来实现，情况往往会复杂很多。单一的技术手段和 解决方案，已经无法应对和满足这些复杂的场景了。 分布式系统的特性 对分布式系统有过研究的读者，可能听说过“CAP 定律”、

微服务–分布式事务的实现方法及替代方案 这两天正在研究微服务架构中分布式事务的处理方案, 做一个小小的总结, 作为备忘. 如有错误, 欢迎指正! 概念澄清 事务补偿机制 : 在事务链中的任何一个正向事务操作, 都必须存在一个完全符合回滚规则的可逆事务. CAP理论 : CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统. 幂等性 : 简单的说, 业务操作支持重试 , 不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID. BASE (Basically avaliable, soft state, eventually consistent): 是分布式事务实现的一种理论标准. 柔性事务 vs. 刚性事务 刚性事务是指严格遵循ACID原则的事务, 例如单机环境下的数据库事务. 柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 两阶段提交(2PC), TCC补偿型提交, 基于消息的异步确保型, 最大努力通知型. 通常对本地事务采用刚性事务, 分布式事务使用柔性事务. 先上结论, 再分别介绍分布式事务的各种实现方式. 如果业务场景需要强一致性, 那么尽量避免将它们放在不同服务中,

原文来自：（ https://www.cnblogs.com/sujing/p/11006424.html ）   分布式事务就是在分布式的场景下，需要满足事务的需求！上篇文章我们聊过了消息中间件，那这篇文章我们要聊的是分布式事务，把两者一结合，便有了基于消息中间件的分布式事务解决方案！不管是本地事务，还是分布式事务，都是为了解决数据的一致性问题！ 一致性 这个词咱们前面多次提及！与本地事务不同的是，分布式事务需要保证的是分布式环境下，不同数据库表中的数据的一致性问题。分布式事务的解决方案有多种，如XA协议、TCC三阶段提交、基于消息队列等等，本文只会涉及基于消息队列的解决方案！    本地事务讲到了一致性，分布式事务不可避免的面临着一致性的问题！回到最开始跨行转账的例子，如果A银行用户向B银行用户转账，正常流程应该是： 1、A银行对转出账户执行检查校验，进行金额扣减。 2、A银行同步调用B银行转账接口。 3、B银行对转入账户进行检查校验，进行金额增加。 4、B银行返回处理结果给A银行。       在正常情况对一致性要求不高的场景，这样的设计是可以满足需求的。但是像银行这样的系统，如果这样实现大概早就破产了吧。我们先看看这样的设计最主要的问题： 1、同步调用远程接口，如果接口比较耗时，会导致主线程阻塞时间较长。 2、流量不能很好控制，A银行系统的流量高峰可能压垮B银行系统