分布式事务

分布式事务了解吗？如果解决分布式事务问题的？ 面试官心里： 只要聊到你做了分布式系统，必问分布式事务，起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。 为什么要有分布式事务？ 分布式事务实现的几种方案： 1. 两阶段提交方案/XA 方案 这种分布式事务方案，比较适合单块应用里。 跨多个库的分布式事务 ，由于因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。 如果要玩儿，那么基于 Spring + JTA 就可以搞定。 这个方案，很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。 如果你要操作别人的服务的库，你必须是通过调用别的服务的接口来实现，绝对不允许交叉访问别人的数据库。 2. TCC(Try, Confirm, Cancel) 方案 使用补偿机制。分三个阶段： Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。 Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。 Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚） 缺点：与业务耦合太紧，事务回滚严重依赖自己的写的代码来回滚和补偿。 适用场景： 与钱打交道的场景，支付，交易 。需要TCC，严格保证分布式事务要么全部成功

这两天正在研究微服务架构中分布式事务的处理方案, 做一个小小的总结, 作为备忘. 如有错误, 欢迎指正! 概念澄清 事务补偿机制: 在事务链中的任何一个正向操作, 都必须存在一个完全符合回滚规则的可逆操作, 这个操作通常叫做rollback或者cancel. CAP理论: CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统. 为什么CA不行呢? 因为没有P的话, 数据一致性会出现问题, 这是任何一个一致性系统不允许出现的情况. 幂等性: 简单的说, 业务操作支持重试, 不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID. BASE(Basically avaliable, soft state, eventually consistent): 是分布式事务实现的一种理论标准. 柔性事务 vs. 刚性事务 刚性事务是指强一致性事务, 例如单机环境下遵循ACID的数据库事务, 或者分布式环境中的2PC等. 柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 异步确保型, 最大努力通知型. 最佳实践 先上结论, 再分别介绍分布式事务的各种实现方式. 如果业务场景需要强一致性,

1. CAP理论 C: Consistency 一致性 A: Availability 可用性 P: Partition tolerance 分区容错性 CAP定理：一个分布式系统不可能同时满足CAP三个要求，最多只能同时满足其中两项。 1.1. CA: 放弃分区容错性，所有数据放一个节点，退回单机模式。 1.2. CP: 放弃可用性，一旦网络故障，受影响服务需要等待恢复时间，系统处于不可用状态。 1.3. AP: 放弃一致性，这里指放弃强一致性，确保最终一致性。 大多数分布式系统的选择。 2. BASE理论 BASE: B ase A vailable(基本可用)， S oft state(软状态), E ventually consistent(最终一致性)。 BASE是对CAP一致性和可用性权衡的结果。 1. 基本可用：指分布式系统出现不可预知故障时，允许损失部分可用性，响应时间合理延长，服务上适当降级。 2. 软状态: 允许分布式系统中的数据处于中间状态，允许各节点数据同步时存在延时。 3. 最终一致性：允许系统中所有数据副本，在经过一段时间同步后，最终能够达到一个一致的状态。不需要实时保证系统的数据一致性。 3. 两阶段提交 (2PC) 数据库支持2PC，又叫XA transactions。 MySQL从5.5版，Oracle从7版，SQL Server 2005开始支持

在分布式系统中，同时满足“一致性”、“可用性”和“分区容错性”三者是不可能的。分布式系统的事务一致性是一个技术难题，各种解决方案孰优孰劣？老司机介绍 丁浪，现就职于某垂直电商平台，担任技术架构师。关注高并发、高可用的架构设计，对系统服务化、分库分表、性能调优等方面有深入研究和丰富实践经验。热衷于技术研究和分享。 在OLTP系统领域，我们在很多业务场景下都会面临事务一致性方面的需求，例如最经典的Bob给Smith转账的案例。传统的企业开发，系统往往是以单体应用形式存在的，也没有横跨多个数据库。 我们通常只需借助开发平台中特有数据访问技术和框架（例如Spring、JDBC、ADO.NET），结合关系型数据库自带的事务管理机制来实现事务性的需求。关系型数据库通常具有ACID特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。 而大型互联网平台往往是由一系列分布式系统构成的，开发语言平台和技术栈也相对比较杂，尤其是在SOA和微服务架构盛行的今天，一个看起来简单的功能，内部可能需要调用多个“服务”并操作多个数据库或分片来实现，情况往往会复杂很多。单一的技术手段和解决方案，已经无法应对和满足这些复杂的场景了。 分布式系统的特性 对分布式系统有过研究的读者，可能听说过“CAP定律”、“Base理论”等，非常巧的是

在分布式系统中，为了保证数据的高可用，通常会将数据保留多个副本（replica）, 这些副本会放置在不同的节点上。这些数据节点可能是物理机器，也可能是虚拟机。为了对用户提供正确的CURD等语意，我们需要保证这些放置在不同节点上的副本是一致的，这就涉及分布式事务的问题。 本文介绍分布式事务处理方案之一的两阶段提交协议。 分布式事务 分布式事务是指发生在多个数据节点之间的事务，分布式事务比单机事务要复杂的多。在分布式系统中，各个节点之间在是相互独立的，需要通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确地知道其他节点的事务执行情况。所以从理论上来讲，两个节点的数据是无法达到一致的状态。如果想让分布式部署的多个节点中的数据保持一致性，那么就要保证在所有节点数据的写操作，要么全部都执行，要么全部都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果，所以它也就不知道本次事务到底应该commit还是rollback。所以，常规的解决办法就是引入一个"协调者"的组件来统一调度所有分布式节点的执行。 为了解决这种分布式一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有二阶提交协议（Two Phase Commitment Protocol）

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 这一几天一直在回顾事务相关的知识，也准备把以前了解皮毛的知识进行一些深入总结，虽然这一些知识并没有用到，但是了解其实现原理还是很有必要的，因为知道了原理，你也能把它实现出来。 在上一节事务的编程模型里面，主要说明了三种编程模型，一般情况下，我们都接触的是单一资源的事务，也就是单独对一个数据库进行操作。如果需要跨多个资源保证事务一致性 举个例子：在ATM机取钱的时候，需要对用户的账户进行扣款处理，然后发送一条消息给消息服务器（假设消息服务器是用JMS实现的），由消息服务器异步通过短信通知用户。如果用户取款失败，那么消息服务器不应该发送短信给用户。如何保证 用户帐务扣款 和 消息服务器的消息保持一致性，也就是说 取款成功，消息服务器就持久化消息，然后发送短信给用户，取款失败，消息服务器就回滚消息，啥都不做。 在上面这种情况下，就需要使用分布式事务，也就是跨越多个资源的保证数据一致性。 X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由这个厂商进行具体的实现。这个思想在java 平台里面到处都是。 X/Open DTP 定义了三个组件： AP

面试官经常问到有关数据库的问题，多数可能就是基于MySQL数据库的这几种引擎。 简介概括主要： 1. 总结： 一般来说不使用事务的话，请使用MyISAM引擎，使用事务的话，一般使用InnoDB。 2. 比较常用的数据库引擎3种： MYISAM：支持3中存储方式：静态型，动态型，压缩型 优点：占用的 空间小 ，存储的 速度快 缺点：不支持 事务 和 并发 使用场景：数据表主要做 修改 和 查询 操作 innoDB: 优点：提供事务的支持，回滚，崩溃修复佛如能力，多版本事务并发控制 缺点：读写效率较差，占用的数据库空间较大 使用场景：MySQL主要引擎 Memory：内存中对数据创建表，数据全部存储在内存 缺点：生命周期短 优点：读写速度非常快，对数据的安全性要求比较低的时候可以选择memory 使用场景：MySQL中使用该引擎作为临时表 3.以下是长篇大论，有兴趣的可以看一下。 InnoDB：支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高（比如银行），要求实现并发控制（比如售票），那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交（commit）和回滚（rollback）。 MYISAM：插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录

事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 数据库事务中的四大特性，ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么要是发不出货，就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。 I:隔离性(Isolation) 指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态

分布式事务LCN的原理 LCN分布式事务框架原理详解4.0 https://blog.csdn.net/gududedabai/article/details/83012487 来源： CSDN 作者： smile-ls 链接： https://blog.csdn.net/qq_40198004/article/details/89469438

1.概述 tx-lcn 官方地址： https://www.txlcn.org/ tx-lcn Github地址： https://github.com/codingapi/tx-lcn TX-LCN定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。 在一个分布式系统下存在多个模块协调来完成一次业务。那么就存在一次业务事务下可能横跨多种数据源节点的可能。TX-LCN将可以解决这样的问题。 TX-LCN由两大模块组成, TxClient、TxManager，TxClient作为模块的依赖框架，提供TX-LCN的标准支持，TxManager作为分布式事务的控制放。事务发起方或者参与反都由TxClient端来控制。 原理图: 核心步骤 创建事务组 是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。 加入事务组 添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。 通知事务组 是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。 更详细的介绍见官网，这里只说明下基础环境的搭建，以及搭建和测试过程中遇到的一些坑