weixiaohuai的博客

一、概述通过前面很多篇文章的讲解和案例开发，相信大家对分布式事务整体有了比较清晰的认识，小伙伴们只要跟着一步一步实现，动动手画画流程图，应该可以对每种方案的实现步骤都有比较深刻的印象。本篇文章主要对比一下之前我们学过的2PC、TCC、可靠消息一致性、最大努力通知方案。二、分布式事务各方案对比分析下面我们分别总结一下各种方案的优缺点：2PC二阶段提交方案二阶段提交的最大缺点就是阻塞时间长，事务参与者RM在执行分支事务后需要等待事务管理者TM的决定，此时服务会阻塞并锁定资源。因此，2PC方案很

目录一、概述二、注册账号案例分析三、第三方支付案例分析四、总结一、概述前面我们已经学习了四种分布式事务解决方案，2PC、TCC、可靠消息最终一致性、最大努力通知，每种解决方案我们通过案例开发进行学习，本篇我们将举几个业务场景，来进行分布式事务解决方案可行性分析。二、注册账号案例分析采用用户、账号分离设计(这样设计的好处是，当用户的业务信息发生变化时，不会影响的认证、授权等系统机制)，因此需要保证用户信息与账号信息的一致性。【a】涉及服务用户微服务：保存用户业务相关数据

目录一、概述二、案例说明和数据库、表准备三、服务注册中心搭建四、搭建充值微服务五、搭建账户微服务六、测试七、总结一、概述前面一篇文章介绍了最大努力通知的整体流程和两种常见的实现方案，本篇文章我们将结合具体的案例【模拟账户充值】详细说明如何利用RocketMQ实现最大努力通知型事务。二、案例说明和数据库、表准备本案例有账户服务和充值服务两个微服务，其中账户服务的数据库是account数据库，其中有张三账户。充值服务的数据库使用recharge 数据库，记录了账户的充

目录一、什么是最大努力通知？二、最大努力通知与可靠消息一致性有什么不同？三、最大努力通知解决方案四、总结一、什么是最大努力通知？最大努力通知也是解决分布式事务的一种方案，我们平常对接支付宝、微信、第三方支付系统时，通常都采用的是最大努力通知方案来保证数据最终一致性的。如上图，是一个账户充值的例子。交互流程大体如下：1、账户系统调用充值系统的接口进行充值； 2、充值系统跳转支付页面； 3、账户系统发起支付请求； 4、充值系统完成支付处理； 5、充值系统发送充

目录一、概述二、案例说明和数据库、表准备三、下载安装RocketMQ并启动四、搭建中国建设银行CCB微服务五、搭建中国工商银行ICBC微服务六、测试转账七、总结一、概述前面一篇文章介绍了RocketMQ实现可靠消息最终一致性事务的整体流程，大部分都是理论知识，本篇文章我们将结合前面我们使用过的【银行转账案例】详细说明如何利用RocketMQ实现可靠消息最终一致性事务。二、案例说明和数据库、表准备案例： 张三【中国建设银行】给李四【中国工商银行】转账说明：张三和

目录一、什么是可靠消息最终一致性事务二、可靠消息最终一致性解决方案之本地消息表方案三、可靠消息最终一致性解决方案之RocketMQ事务消息方案四、可靠消息最终一致性解决方案之RocketMQ事务消息案例流程分析五、总结一、什么是可靠消息最终一致性事务可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(即消息消费方)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方，事务参与方无论如何都要消费掉，并且事务最终要达到一致。此方案是

目录一、概述二、案例说明和数据库、表准备三、服务注册中心搭建四、搭建中国建设银行BBC微服务五、搭建中国工商银行ICBC微服务六、测试七、总结一、概述前面一篇文章，我们已经详细介绍了TCC是如何处理分布式事务，主要分别三个阶段：try：负责业务检查及资源预留； confirm：用来执行业务逻辑； cancel：实现一个与Try相反的操作既回滚操作；前面一篇文章，大部分都是理论相关知识，我们都知道理论必须结合实践才能加深对其理解，所以本篇文章我们将会以一个银行转账

目录一、概述二、TCC原理图三、TCC解决方案四、TCC方案常见问题五、案例说明六、总结一、概述TCC是Try、Confirm、Cancel三个词语的缩写，TCC协议采用预处理Try、确认Confirm、撤销Cancel三个阶段来处理分布式事务。其中：try：负责业务检查及资源预留； confirm：用来执行业务逻辑； cancel：实现一个与Try相反的操作既回滚操作；TM事务管理器首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会

目录一、业务说明二、环境准备三、搭建Eureka服务注册中心四、搭建用户微服务五、搭建积分微服务六、测试七、Seata执行流程八、总结一、业务说明本篇文章将通过Seata第三方分布式事务框架，模拟新用户注册的同时，赠送用户积分过程。用户微服务，插入新用户信息，连接用户数据库；积分微服务，插入用户积分信息，连接积分数据库；上述两个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务，由于跨JVM进程，所以必然需要处理分布式事务，否则可能存在数据不一致问题。

目录一、概述二、XA解决分布式事务三、总结一、概述前面一篇文章我们已经对2PC两阶段提交解决分布式事务方案进行了详细的介绍，并介绍了常见的两种方法：XA协议方案； Seata方案；本篇文章我们将总结使用Springboot整合多数据源，Mybatis+jta+automatic实现分布式的事务，其实是XA方案的一个实现。注意：这里的多数据源采用分包的方式。二、XA解决分布式事务本案例我们使用的是MySQL数据库，MySQL是支持XA协议的，数据库驱动中也有一个co

一、概述前面一篇文章我们已经学习了分布式事务的基础理论，以理论为基础，针对不同的分布式场景业界常见的解决方案有2PC、TCC、可靠消息最终一致性、最大努力通知这几种。下面我们先回顾一下分布式事务基础知识：什么是分布式事务？分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。分布式事务的产生的原因？ 数据库分库分表简单的说就是原来的一个数据库变成了多个数据库，应用程序一个

一、概述通过前面的学习，我们了解到了分布式事务的基础概念。与本地事务不同的是，分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同机器上，相互之间通过网络交互。不能因为有一点网络问题就导致整个系统无法提供服务，网络因素成为了分布式事务的考量标准之一。因此，分布式事务需要更进一步的理论支持，接下来，我们先来学习一下分布式事务的CAP理论。在讲解分布式事务控制解决方案之前需要先学习一些基础理论，通过理论知识指导我们确定分布式事务控制的目标，从而帮助我们理解每个解决方案。二、CAP理论CAP是

目录一、什么是事务二、本地事务三、分布式事务四、分布式事务产生的场景五、总结一、什么是事务事务是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行；事务是一组不可再分割的工作单元（工作逻辑单元）。上面的概念稍稍有些抽象，不好理解，我们举个生活中的例子：假设张三给李四转账100元， "张三账户余额扣减100元"和"李四账户增加100元"就是一个典型的事务的例子。 "张三账户余额扣减100元"和"李四