分布式事务

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

1.流程图 步骤： 1.在给mq发送消息的时候，发送一个“半消息”，具有事务的消息 2.实现 实现两个方法 在第一个方法中实现本地事务的提交，提交的同时在数据库中记录一个成功日志，以便二次确认时候判断是否成功，如果没有异常，该方法返回一个具有commit的事务对象，反之回滚 在第二个方法做二次确认，根据transactionid 查询数据库做二次确认。 来源： https://www.cnblogs.com/longsanshi/p/11920937.html

目录： 1.什么是事务？ 2.换个角度看事务 3.Java中的事务 4.啥又是分布式事务？ 5.分布式事务的几种实现思路 6.总结 写在前面 在分布式、微服务大行其道的今天，相信大家对这些名词都不会陌生。而说到使用分布式，或者拆分微服务的好处，你肯定能想到一大堆。 比如每个人只需要维护自己单独的服务，没有了以前的各种代码冲突。自己想测试、想发布、想升级，只需要care自己写的代码就OK了，很方便很贴心！ 然而事物都有两面性，但是它也同时也会带来的一些问题，今天的文章谈的就是分布式系统架构带来的其中一个棘手的问题： 分布式事务 1、什么是事务？ 首先抛出来一个问题：什么是事务？ 有人会说事务就是一系列操作，要么同时成功，要么同时失败；然后会从事务的ACID特性（原子性、一致性、隔离性、持久性）展开叙述。 确实如此，事务就是为了保证一系列操作可以正常执行，它必须同时满足ACID特性。 但是今天我们 换个角度思考下，我们不仅要知道what（比如什么是事务），更要知道事务的why（比如为什么会有事务这个概念？事务是为了解决什么问题）。 有时候，换个角度说不定有不一样的收获。 2、换个角度看事务 就像经典的文学作品均来自于生活，却又高于生活，事务的概念同样来自于生活，引入“事务”肯定是为了解决某种问题，不然，谁又愿意干这么无聊的事情呢？ 最简单最经典的例子： 银行转账

#0 系列目录# 分布式事务 【分布式事务系列一】提出疑问和研究过程 【分布式事务系列二】Spring事务管理器PlatformTransactionManager 【分布式事务系列三】Spring的事务体系 【分布式事务系列四】分布式事务的概念 【分布式事务系列五】jotm的分布式案例 【分布式事务系列六】jotm分布式事务源码分析 【分布式事务系列七】Atomikos的分布式案例 【分布式事务系列八】JTA深度历险-原理与实现 在 J2EE 应用中，事务是一个不可或缺的组件模型， 它保证了用户操作的 ACID（即原子、一致、隔离、持久）属性 。对于只操作单一数据源的应用，可以通过本地资源接口实现事务管理；对于跨数据源（例如多个数据库，或者数据库与 JMS）的大型应用，则必须使用全局事务 JTA (Java Transaction API)。 JTA 为 J2EE 平台提供了分布式事务服务，它隔离了事务与底层的资源，实现了透明的事务管理方式 。 #1 利用 JTA 处理事务# ##1.1 什么是事务处理## 事务是计算机应用中不可或缺的组件模型， 它保证了用户操作的原子性 ( Atomicity )、一致性 ( Consistency )、隔离性 ( Isolation ) 和持久性 ( Durabilily ) 。关于事务最经典的示例莫过于信用卡转账：将用户 A 账户中的

在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗，业务调用的时延将增大，同时由于网络闪断等原因，分布式调用失败的风险也增大。如果服务框架没有足够的容错能力，业务失败率将会大幅提升。 除了性能、可靠性等问题，跨节点的事务一致性问题、分布式调用带来的故障定界困难、海量微服务运维成本增加等也是分布式服务框架必须要解决的难题。本章节我们将对服务化之后面临的挑战进行分析，并给出解决方案和业务最佳实践。 1. 性能和时延问题 在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗： 1） 客户端需要对消息进行序列化，主要占用CPU计算资源。 2） 序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。 3） 客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。 4） 服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。 5） 服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。 6） 服务端将响应结果序列化，占用CPU计算资源。 7） 服务端将应答码流发送给客户端，占用网络带宽资源。 8） 客户端读取应答码流，反序列化成响应消息，占用CPU资源。

在大型系统架构时我们会进行分库设计，比如用户库、订单库。如果采用了dubbo会产生服务,如果目前有两个服务，用户服务和订单服务。 实际业务中，用户下单支付成功后，并改变用户的状态或增加用户的积分。这样过程中就会产生事务问题。这里我们采用最终事务一致性。 大致实现思路，把分布式事务切割成小事务，用消息队列消除分布式事务。实现方式如下： 订单功能的小事务如下： 首先：订单服务。 jmsTemplate.setSessionTransacted(true); transactionTemplate.execute(new TransactionCallback<String>() { @Override public String doInTransaction(TransactionStatus status) { // TODO Auto-generated method stub Connection connection = null; Session session = null; try { String orderId = System.currentTimeMillis() + ""; String sql = "insert into order (order_id,user_id) values (?,?)"; jdbcTemplate.update(sql, new

FROM： https://www.cnblogs.com/jajian/p/10014145.html 之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章： 《拜托，面试请不要再问我Spring Cloud底层原理！》 。 1 | 0 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 2 | 0 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子

1、一致性 1.1、简述 　　一致性，是指对每个节点一个数据的更新，整个集群都知道更新，并且是一致的，假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性： 全认同 ：所有N个节点都认同一个结果 值合法 ：该结果必须由N个节点中的过半节点提出 可结束 ：决议过程在一定时间内结束，不会无休止地进行下去 1.2、面临着的问题　 消息传递异步无序： 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序 节点宕机： 节点持续宕机，不会恢复 节点宕机恢复： 节点宕机一段时间后恢复，在分布式系统中最常见 网络分化： 网络链路出现问题，将N个节点隔离成多个部分 拜占庭将军问题： 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息 2、2PC 2.1、简述 　　2PC(tow phase commit)两阶段提交 　　 　　所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)。 2.2、阶段1 　　 在阶段1中，协调者发起一个提议，分别问询各参与者是否接受，如下图： 　　 2.3、阶段2 　　 在阶段2中，协调者根据参与者的反馈，提交或中止事务，如果参与者全部同意则提交

1、 CAP 的来源 　　1998年，加州大学的计算机科学家EricBrewer提出，分布式系统有三个指标 C onsistency：一致性 A vailability：可用性 P artition tolerance：分区容错性 　　它们的第一个字母分别是 C、A、P，EricBrewer说这三个指标不可能同时做到，最多只能3选2，这个结论就叫做 CAP 定理。 2、如何取舍？ 　　 CA ： 如果不要求P（不允许分区），则C（一致性）和A（可用性）是可以保证的，CA系统基本上是单机系统，比如单机数据库。 　　 CP ：如果不要求A（可用性），相当于每个请求都需要在Server之间强一致，而P（分区容错性）会导致同步时间无限延长，如此CP也是可以保证的，很多传统的数据库分布式事务都属于这种模式。 　　 AP ：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。 来源： https://www.cnblogs.com/jackcto/p/11904605.html

BASE 模型是CAP定理牺牲强一致性、保证可用性的折中方案： 1、 B asically A vailable-基本可用 　　分布式系统发生不可预知的故障时，允许损失部分可用性，如服务降级等。 2、 S oft state-弱状态 　　分布式系统不同节点间某个时刻数据允许存在中间状态，不同节点的数据副本之间进行同步时可能存在时延，如主从同步。 3、 E ventually consistent-最终一致 　　分布式系统不同节点的所有数据副本，在经过一段时间数据同步后，最终达到一致状态，即保证最终一致性，不保证实时一致性。 我们通常接触的常见中间件，如mysql、zookeeper、redis、elasticsearch等都是基于BASE理论建立的 来源： https://www.cnblogs.com/jackcto/p/11904616.html