分布式事务

摘自： https://www.cnblogs.com/xiaoXuZhi/p/xyh_trans_distributed.html 关于分布式事务的实现梳理 关于分布式事务的实现梳理 场景描述 　　在实际开发过程中，往往会遇到微服务架构中（数据分区存储），用户的一个操作，会设计到多个模块的数据落地或者更新查找，并且每个模块数据都是存储在不同的数据库，并且业务要求还需要确保操作结果的一致性。比如，用户在下单时：首选需要落地订单数据，其次，需要落地：账单数据、日志数据、或者库存更新等等操作。首先我们想到的解决方式就是事务来实现，由于在不同库，所以需要涉及到分布式事务。 解决方案 　　为了达到上述要求，在实现上根据我的经验大概有如下3种实现方式： 　　其一、分布式事务 　　　　分布式事务就是采用微软提高的分布式事务机制实现，在实现效率上不是很理想，并且也不是符合微服务设计的单一功能原则，所以不是很建议使用。 　　其二、消息队列 　　　　消息队列是现在使用的比较多的解决方案，通过一些消息队列中间件， 实现逻辑解耦，异步实现，响应效率也大大提升。 　　其三、异步作业 　　　　异步作业的实现思路和消息队列类似，都是对操作的步骤的解耦，异步实现，但是在处理上有一定的延迟性，因为异步作业是周期性的执行，但是异步作业也是对消息队里的一个保障和补充。 　　　　在实际使用过程中

关于分布式事务的实现梳理 场景描述 　　在实际开发过程中，往往会遇到微服务架构中（数据分区存储），用户的一个操作，会设计到多个模块的数据落地或者更新查找，并且每个模块数据都是存储在不同的 数据库 ，并且业务要求还需要确保操作结果的一致性。比如，用户在下单时：首选需要落地订单数据，其次，需要落地：账单数据、日志数据、或者库存更新等等操作。首先我们想到的解决方式就是事务来实现，由于在不同库，所以需要涉及到分布式事务。 解决方案 　　为了达到上述要求，在实现上根据我的经验大概有如下3种实现方式： 　　其一、分布式事务 　　　　分布式事务就是采用微软提高的分布式事务机制实现，在实现效率上不是很理想，并且也不是符合微服务设计的单一功能原则，所以不是很建议使用。 　　其二、消息队列 　　　　消息队列是现在使用的比较多的解决方案，通过一些消息队列中间件， 实现逻辑解耦，异步实现，响应效率也大大提升。 　　其三、异步作业 　　　　异步作业的实现思路和消息队列类似，都是对操作的步骤的解耦，异步实现，但是在处理上有一定的延迟性，因为异步作业是周期性的执行，但是异步作业也是对消息队里的一个保障和补充。 　　　　在实际使用过程中，一般都是消息队列和异步作业配套实现，当消息队列出现问题，异步作业能正常的把流程走完。 　　分布式事务 　　在介绍分布式事务时，分两部分来介绍：sql分布式事务、ADO

1.XA XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲（参考Fischer等的论文），两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源（如数据库或JMS队列）。下图说明了事务管理器、资源管理器，与应用程序之间的关系： 图1.XA规范下的分布式事务各类参与者之间的关系 2.JTA 作为java平台上事务规范JTA（Java Transaction API）也定义了对XA事务的支持，实际上，JTA是基于XA架构上建模的，在JTA 中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。像很多其他的java规范一样，JTA仅仅定义了接口，具体的实现则是由供应商(如J2EE厂商)负责提供，目前JTA的实现主要由以下几种： 1

1.XA XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲（参考Fischer等的论文），两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源（如数据库或JMS队列）。下图说明了事务管理器、资源管理器，与应用程序之间的关系： 图1.XA规范下的分布式事务各类参与者之间的关系 2.JTA 作为java平台上事务规范JTA（Java Transaction API）也定义了对XA事务的支持，实际上，JTA是基于XA架构上建模的，在JTA 中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。像很多其他的java规范一样，JTA仅仅定义了接口，具体的实现则是由供应商(如J2EE厂商)负责提供，目前JTA的实现主要由以下几种： 1

本人免费整理了Java高级资料，涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程，一共30G，需要自己领取。 传送门： https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q 目录 一、分布式锁 数据库的唯一索引 Redis 的 SETNX 指令 Redis 的 RedLock 算法 Zookeeper 的有序节点 二、分布式事务 2PC 本地消息表 三、CAP 一致性 可用性 分区容忍性 权衡 四、BASE 基本可用 软状态 最终一致性 五、Paxos 执行过程 约束条件 六、Raft 单个 Candidate 的竞选 多个 Candidate 竞选 数据同步 一、分布式锁 在单机场景下，可以使用语言的内置锁来实现进程同步。但是在分布式场景下，需要同步的进程可能位于不同的节点上，那么就需要使用分布式锁。 阻塞锁通常使用互斥量来实现： 互斥量为 0 表示有其它进程在使用锁，此时处于锁定状态； 互斥量为 1 表示未锁定状态。 1 和 0 可以用一个整型值表示，也可以用某个数据是否存在表示。 数据库的唯一索引 获得锁时向表中插入一条记录，释放锁时删除这条记录。唯一索引可以保证该记录只被插入一次，那么就可以用这个记录是否存在来判断是否存于锁定状态。

前言 在系统变的复杂后，分布式、微服务等架构技术，就要考虑到应用在系统中了。尤其数据量大了后，就需要 对数据库进行拆分。 如：注册的用户数据，量大了后，就需要考虑分库分表 一旦数据库进行了分拆，那就出现很多头疼的问题， 其中之一就是事务问题 。那我们就来看看问题是怎么出现的？ 场景 先来上个图 进行数据拆分后，就类似上面的架构。 上图中我们就拿用户的数据进行举例， 用户量一旦几千万时 ，就需要进行分库分表；上图就分了3个库，每个库都保证了高可用。 这样的架构设计，会遇到事务问题，我们来看看具体的业务场景：用户A转账100元给用户B，这个业务比较简单，我们来分析一下里面具体的步骤： 1、用户A的账户先扣除100元 2、再把用户B的账户加100元 逻辑很简单，上伪代码 代码也是比较清晰的，感觉没有什么问题， 那我们来分析一下问题在哪？ 问题 我们看到在转账业务中， 有两步，一个是操作用户A扣钱，一个是操作用户B加钱 如果在同一个数据库中进行，可以保证这两步操作，要么同时成功，要么同时不成功。这样就保证了转账的数据一致性。 但是如果用户A的数据在集群A中，用户B在集群B中呢？ 因为他们不在同一个事务中；如用户A扣款成功，但用户B加钱失败了；那就坑了，数据不完整了。 类似这种问题在微服务架构会更多，因为各个服务都是独立的模块，都是远程调用，都没法在同一个事务中，都会遇到事务问题。

1.ZooKeeper是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。 Zookeeper保证了如下分布式一致性特性： 顺序一致性 原子性 单一视图 可靠性 实时性（最终一致性） 客户端的读请求可以被集群中的任意一台机器处理， 如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理 。对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。 有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。 Zookeeper提供了文件系统和通知机制。Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是

前言 这篇文章将给大家介绍一下对分布式事务的一些见解，并讲解分布式事务处理框架 TX-LCN 的执行原理，错误之处望各位不吝指正。 1. 什么情况下需要使用分布式事务？ 使用的场景很多，先举一个常见的：在微服务系统中，如果一个业务需要使用到不同的微服务，并且不同的微服务对应不同的数据库。 打个比方：电商平台有一个客户下订单的业务逻辑，这个业务逻辑涉及到两个微服务，一个是库存服务（库存减一），另一个是订单服务（订单数加一），示意图如下： 如果在执行这个业务逻辑时没有使用分布式事务，当库存与订单其中一个出现故障时，就很可能出现这样的情况：库存数据库的值减少了 1，但是订单数据库没有变化；或是库存没变化，多了一个订单，也就是出现了数据不一致现象。 所以在类似的场合下我们要使用分布式事务，保证数据的一致性。 2. 分布式事务的解决思路 2.1引入：MySQL 中的两阶段提交策略 在谈分布式事务的解决思路之前，我们先来看看单一数据源是如何做事务处理的，我们可以从中获取一些启发。 我们以 MySQL 的 InnoDB 引擎为例，由于 MySQL 中有两套日志机制，一套是存储层的 redo log，另一套是 server 层的 binlog，每次更新数据都要对两个日志进行更新。为了防止写日志时只写了其中一个而没有写另外一个，MySQL 使用了一个叫 两阶段提交 的方式保证事务的一致性

摘抄并学习 1. 微服务的发展 　　微服务倡导将复杂的单体应用拆分成若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性。便于敏捷开发。当前微服务的开发框架非常多，比较著名的有 Dubbo、SpringCloud、thrift、grpc 等。 2. 微服务落地存在的问题 　　虽然现在微服务如火如荼，但对其实践仍处于探索阶段。很多中小型互联网公司鉴于经验技术实力等问题，微服务落地比较困难。主要有以下几个方面： 　　1）单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变得更加复杂。 　　2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题非常突出。 　　3）微服务数量众多，其测试、部署、监控等都变得更加困难 　　随着 RPC（远程过程调用 Remote Procedure Call） 框架的成熟，第一个问题已经逐渐得到解决。例如 dubbo 可以支持多种通讯协议，springcloud 可以非常好的支持 restful 调用。对于第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。 　　以下介绍分布式事务的各种解决方案，重点解读阿里巴巴提出的分布式事务解决方案 —— GTS。 3. SOA分布式事务解决方案 3.1 基于 XA

转：https://www.cnblogs.com/sujing/p/11006424.html 前两天发了工资，第一反应是想着要给远方的女朋友一点惊喜！于是打开了平安银行的APP给女朋友转点钱！填写上对方招商银行卡的卡号、开户名，一键转账！搞定！在我点击的那瞬间，就收到了app的账户变动的提醒，并且出现了图一所示的提示界面：“处理中，正在等待对方银行返回结果…”。嗯！毕竟是跨行转账嘛，等个几秒也正常！脑海开始浮现出女朋友收到转账后惊喜与感动的画面！       然而，一切并没有那么顺利，刚过一会儿，app却如图二所示的提示我“由于收款人户名不符”导致转账失败！！！       刚刚都已经从我卡里扣过钱了，现在却提示我转账失败，银行会不会把我的钱给吞了？转账失败的钱还能退换给我吗？正在我紧张、焦虑、坐立不安之时又收到一条app冲正的消息，刚刚转账失败的钱已经退还给我了，看来我多虑了……这也证明咱平安银行的app还是比较安全靠谱的！    为啥从我卡里扣钱那么迅速，而对方却要几秒才能到账？并且转账失败后，扣除的钱还能及时的返还到我的卡里？万一钱返还失败怎么办？又或者我转一次钱，对方却收到了两次转账的申请又该如何？带着这些问题，我脑海中浮现出“事务”二字！    在我们还在“牙牙学语”的时候，老师经常会通过转账的栗子来跟我们讲解事务，但跟这里场景不一样的是，老师讲的是本地事务