分布式事务解决方案几乎都是柔性事务，常见的有2PC/3PC、TCC、MQ最终一致性解决方案，至于工作中用哪种方案，需要根据业务场景选取，2PC/3PC、TCC数据强一致性高，而MQ是最终数据一致。
前两天有个学弟公众号留言，说让讲讲分布式事务，面试就挂在这个问题上。时下随着微服务架构体系的流行，面试的题目也都慢慢开始升级，不再是早些年单纯的问点SSH框架知识、数据结构了。高并发、高可用、分布式服务治理、分布式文件系统、分布式xxx，反正和分布式沾边的都会问点， 项目实际用不用不要紧，关键你得了解，是不是总有一种学不动了的感觉？
还记得刚入行开始写Java时，接触的第一个项目是国家电网的一个业务系统，这个系统据说投资了5亿人民币进行研发，鼎盛时期研发人员一度达到过500人。项目采用当时最流行的ssh（Struts+Spring+Hibernate）框架，典型的三层架构（controller - > service -> dao）简单又粗暴，所有人写的代码都放在一个大工程里，项目文件大小达到几百M，解决代码冲突是当时最大的工作量。
前面我们说了两期分布式事务模型，分别是2PC和3PC，2PC模型它的效率比较低，并且会出现事务阻塞等问题，所以引入了3PC模型， 3PC模型在2PC模型的基础上进行了改进，避免了事务阻塞问题，不过对于2PC和3PC模型，他们依然是阻塞的，也就是说当前事务在 执行的过程中，其他事务都会被阻塞，所以实际上他们的效率都不高，如果对于并发量不发的系统，那么可以选择它们，但是在高并发的 场景下，用2PC模型和3PC模型，显然就不行了，所以今天我们引入了TCC模型。
上一篇文章已经讲完分布式了，那暖男说要讲分布式事务那就一定会讲，只是我估计大家没料到暖男这么快就肝好了吧？
上一次我们讲解了分布式事务的 2PC、3PC 。那么这次我们来理一下 TCC 事务。本次还是讲解 TCC 的原理跟 .NET 其实没有关系。
对于分布式事务，相信所有人都应该很了解，为什么会有分布式事务？无论是数据量导致的分库，还是现在微服务盛行的场景都是他出现的原因。
事务是数据库从一个稳定状态变迁到另一个稳定状态的保证，具备 ACID 这 4 个特性：
Innodb采用MVCC多版本并发控制实现读写并发执行，并且以此来支持读已提交和可重复读两个隔离级别，核心在于快照创建时间点不同，前者是每次select时创建快照版本，后者是在事务开始时创建快照版本。
在上一篇文章《【分布式事务】基于RocketMQ搭建生产级消息集群？》中给大家介绍了基于RocketMQ如何搭建生产级消息集群。因为本系列文章最终的目的是介绍基于RocketMQ的事物消息来解决分布式系统中的数据一致性问题，所以先给大家率先介绍了RocketMQ消息集群的搭建。
在微服务架构盛行的情况下，在分布式的多个服务中保证业务的一致性，即分布式事务就显得尤为重要。本文将讲述分布式事务及其解决方案，有XA协议、TCC和Saga事务模型、本地消息表、事务消息和阿里开源的Seata。
最近比较忙，好久没更新了。这次我们来聊一聊分布式事务。 在微服务体系下，我们的应用被分割成多个服务，每个服务都配置一个数据库。如果我们的服务划分的不够完美，那么为了完成业务会出现非常多的跨库事务。即使按照 DDD 的原则来切分服务还是免不了有的业务场景需要多个业务同时提交成功或者同时回滚的场景。比如会员使用积分下订单这个场景，那么会员服务的积分扣减需要跟订单下单成功同时完成。如果下单成功，但是扣减积分接口失败，那么就会造成数据的不一致性。这个时候我们就需要使用分布式事务来保证数据的一致性。 由于分布式事务要介绍的东西比较多，这一篇只介绍 2PC、3PC 的基本概念，所以 .net 相关的内容大概也只会出现在标题上一次，笑哭。
大家好，我是小❤，一个漂泊江湖多年的 985 非科班程序员，曾混迹于国企、互联网大厂和创业公司的后台开发攻城狮。
刚性事务：顾名思义，非常的“刚”，属于硬刚的那种。这个分布式事务要么全成功，要么全回滚，别跟我提什么中间状态，我的人生中不允许出现模棱两可。其中包括：XA、2PC、3PC
参与者将本身事务的执行情况发送给事务协调者，由事务协调者判断事务调用链是否执行提交操作还是回滚操作
事务提供一种机制将活动中涉及所有操作纳入到一个不可分割的执行单元。整个单独单元作为一个不可分割的整体，如果单元中某条sql语句一旦执行失败或者产生错误，整个单元将会回滚，也就是所有受到影响的数据将会返回到事务开始以前的状态；如果单元中的所有sql语句均执行成功，则事务被顺利执行。
单体数据库不涉及网络交互，所以在多表之间实现事务是比较简单的，这种事务称之为本地事务。
事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。
前面几篇《打开我的收藏夹》文都让我受益匪浅，在此我还是想说一句：都是自己当初收藏的，就不要吃灰了，逐渐放空掉自己的收藏夹未必不是一件好事。
这次使用分布式事务框架过程中了学习了一些分布式事务知识，所以本文我们就来聊聊分布式事务那些事。首先我们先回顾下什么是事务。
事务（Transaction）是并发控制的单位，是用户定义的一个操作序列。 这些操作要么都做，要么都不做，是一个不可分割的工作单位。
分布式一致性是一个常见的问题，比如在本地表中插入了一条记录，同时又远程调用了一个服务，很有可能插入记录成功了，但远程调用超时了，亦或本地记录插入成功了，此时刚好机器重启了......我们遇到的实际问题远非这个例子，根据自己的经验，在业务初期，很少关注这种一致性问题，有两方面的问题：一是这种发生的概率较小，就没有花时间去解决；二是业务在快速跑，容忍了这种异常场景存在。在本篇文章中会全方面位分析分布式一致性的问题、业内标准解决方案、实际工作解决方法
看标题就知道，这个又是个在面试中被问到的问题。这个问题其实是在我上次换工作的时候面试被问到过几次，之前也没在意过，觉得这个东西可能比较深奥，我直接说不理解吧。但是随着Java开发这个行业越来越卷，这次换工作一定要做好充足的准备。把之前落下的坑都填好，再出去受虐（面试）。
分布式事务的基本概念与本地事务类似，都保证了 ACID 特性（见[本篇第二章](# 二. 事务的特性)）。随着数据的规模越来越大，就出现了对业务的解构，包括数据层面的关系型数据库的垂直、水平分表，以及服务层面的拆分，将一个大服务拆分为后单独部署，甚至同时也将数据库独立出来。这时候本地数据库事务就不能满足多个数据库、异构系统的原子性、持久性了，需要使用分布式事务的方法。通常，分布式事务只需要保证原子性，通过保证原子性来保证应用层面的一致性，由本地事务保证隔离性和持久性。 从 CAP 特性上考虑，由于分布式事务存在网络分割的情况，所以一定需要满足分区容忍性，剩下的需要在一致性 (Consistency) 与可用性 (Available) 之间做权衡。下面提到各种分布式事务的实现方法与协议，都是需要在一致性与可用性之间权衡的。
在分布式事务中，通常使用两阶段协议或三阶段协议来保障分布式事务的正常运行，它也是 X/Open 公司定义的一套分布式事务标准。
分布式事务学习项目：流量充值中心 git地址：https://github.com/barrywangmeng/data-refill-center
事务（Transaction）：一般是指要做的或所做的事情，由 事务开始(begin transaction) 和 事务结束(end transaction) 之间执行的全体操作组成。
在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于CAP理论以及BASE理论，有人就提出了柔性事务的概念。在业内，关于柔性事务，最主要的有以下四种类型：两阶段型、补偿型、异步确保型、最大努力通知型几种。我们前边讲过的2PC和3PC都属于两阶段型，两阶段型事务存在长期锁定资源的情况，导致可用性差。接下来我们来介绍的TCC则是补偿型分布式事务。
前面我们讲了分布式事务的基本概念，CAP理论等，也讲了2pc协议，3pc协议，我们可以暂时认为2pc协议，3pc协议他们是传统的事务处理机制，这一篇，我们讲一讲TCC（Try-Confirm-Cancel） 事务机制，相对于传统事务机制（X/Open XA Two-Phase-Commit），TCC的特别之处在于它不依赖资源管理器(RM)对XA的支持，而是通过对业务逻辑（由业务系统提供的）的调度来实现分布式事务。
完成某件事情，可能有多个参与者需要执行多个步骤，最终多个步骤要么全部成功，要么全部失败。
松哥最近正在录制 TienChin 项目视频～采用 Spring Boot+Vue3 技术栈，里边会涉及到各种好玩的技术，小伙伴们来和松哥一起做一个完成率超 90% 的项目，戳戳戳这里-->TienChin 项目配套视频来啦。 ---- 说好了写 TienChin 项目的，最近这个分布式事务算是一个支线任务吧，今天是最后一篇，松哥再来一个短篇和小伙伴们总结一下分布式事务。 首先先说一个大原则：分布式事务能不用就不要用，毕竟这个用起来还是有一些麻烦的。当然，不用和不会用可是两码事。 1. 分布式事务基础理论
传统单机服务，保证ACID是很容易的，但随着业务量的提升，订单系统，财务系统，人员管理系统都需要拆分成独立的模块，单个服务器已经无法满足这么大的负载，所以每个独立的模块都需要安装在单独的服务器。
上一篇文章我们将整个交易系统进行了微服务化，拆分为了多个相互独立的业务组件，每个业务组件不只是包含自己业务的微服务，还包括了独立管理的数据库。那么，我们来考虑下单的场景，用户下委托单的时候，主要有三步操作：一是冻结金额，二是新增订单，三是投递给到撮合引擎。这三步需要保证事务的一致性。在服务和数据库都不拆分的情况下，是很容易满足的。但拆分之后，这几个步骤的操作也分开到不同业务组件了，服务是分开的，数据库也是分开的。在这种分布式的环境下，又要如何保证事务的一致性，这就是分布式事务问题了。
C：一致性被称为原子对象，任何的读写都应该看起来是“原子”，或串行的。写后面的读一定能读到前面写的内容，所有的读写请求都好像被全局排序。 A：对任何非失败节点都应该在有限时间内给出请求的回应。（请求的可终止性） P：允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失
所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。
好长时间没发文了，最近着实是有点忙，当爹的第 43 天，身心疲惫。这又赶上年底，公司冲 KPI 强制技术部加班到十点，晚上孩子隔两三个小时一醒，基本没睡囫囵觉的机会，天天处于迷糊的状态，孩子还时不时起一些奇奇怪怪的疹子，总让人担惊受怕的。
如果说「共识」解决的是「水平」问题，那么「事务」解决的是「垂直」问题。是如何让一条绳上的蚂蚱共同起舞？
在这一篇中主要讲述分布式基础理论知识,其中包含CAP定理,ACID以,BASE理论以及一致性协议分析.有了CAP定理的基础,能够帮助我们在根据业务特点进行分区容错一致性模型设计中提供解决问题的方向以及架构设计方案的设计与落地实现.同时需要区分数据库ACID的AC与我们的分布式AC存在的联系与差异,其次,在分布式网络中,为避免节点故障抑或是网络延迟等问题导致系统服务出现大量的不可用问题,那么对于BASE理论实现的技术方案有哪些.最后讲述分布式系统中数据的一致性问题.
本文是本系列的第三篇。与前两篇《不知道是不是最通俗易懂的《数据一致性》剖析了》、《烦人的数据不一致到底怎么解决？——通过“共识”达成数据一致性》形成完整的「数据一致性」合集。
实现分布式一致性的算法有很多种，各有优缺点，适用不同的场景 算法 一致性 性能 实现复杂度 依赖组件 是否侵入业务 其他 2PC/3PC 强一致性 差 复杂 依赖存储组件实现 无侵入 TCC 强一致性 一般 复杂 不依赖组件 需要提供try/confirm/cancel接口 本地消息表 最终一致性 好 简单 不依赖 基本无侵入 只能用在其他逻辑只能成功的场景 SAGA 最终一致性 好 一般 不依赖 业务需要提供补充逻辑以及监听其他子事务的事件 参考 分布式事务系列三：Saga
我们先看看百度上对于分布式事务的定义：分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
分布式场景下，多个服务同时对服务一个流程，比如电商下单场景，需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败，或者网络不通引起的请求丢失，那么整个系统可能出现数据不一致的原因。
传统单体应用一般都会使用一个关系型数据库，好处是使用ACID事务特性，保证数据一致性只需要开启一个事务，然后执行更新操作，最后提交事务或回滚事务。更方便的是可以以借助于Spring等数据访问技术和框架后只需要关注引起数据改变的业务本身即可。
最近有群友学习了总结了一些微服务下数据一致性的特点，涵盖了目前的保障微服务下数据一致性的几种实现方式如下，以备后查。此篇文章旨在给大家一个基于微服务的数据一致性实现的大概介绍，并未深入展开，具体的实现方式本人也在继续学习中，如有错误，欢迎大家拍砖。
2PC，两阶段提交，将事务的提交过程分为资源准备和资源提交两个阶段，并且由事务协调者来协调所有事务参与者，如果准备阶段所有事务参与者都预留资源成功，则进行第二阶段的资源提交，否则事务协调者回滚资源。
想象一下，当最后一张火车票同时被两个人购买，去检票口检票时被告知车票无效，这可以接受吗？
大家好，我是老三，上次发文的时候还是上次发文的时候，这篇文章分享分布式事务，看完要是你们不懂，那一定是不明白。
本文是本系列的第三篇。与前两篇《分布式系统关注点——数据一致性（上篇）》、《分布式系统关注点——通过“共识”达成数据一致性》形成完整的「数据一致性」合集。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
