保暖透气大裤衩LeoLee的博客

什么是最大努力通知分布式系统中，服务之间的互相调用有时候在某些业务场景下，被调用者需要将业务处理结果再通知到调用者，调用者才能继续完成后续的业务操作，在这种场景下要保证业务的连续性、完整性、最终一致性等，就需要消息通知的可靠性至关重要。结合以上的分析，最大努力通知就是服务间的消息通知，要尽可能的设计和使用某些策略手段，达到最接近100%的通知成功率。场景简单举栗下单扣减库存场景：订单服务收到下单的请求开始执行下单业务逻辑 订单服务处理了一定的前置业务逻辑后，需要通知库存服务扣减库存 库存

什么是可靠消息最终一致性指的是当事务发起方执行完成本地事务后并发送一条消息，事务参与方（消息的消费者）一定可以收到该消息，并完成接下来的业务处理，保证事务的成功。在此方案中，强调的是最终一致性，这就要保证发送的消息是一定能被事务参与者接收到的。完成消息通知是需要使用消息中间件：MQ事务发起方执行业务开启事务，发送消息到消息中间件 事务参与者监听消息中间件的队列，从队列中获取消息 在消息的传递过程中，消息是必须可靠的，必须能被事务参与者获取到的，这就是消息的可靠性 在事务的参与者接收到消

大伙可以到我的RabbitMQ专栏获取更多信息RabbitMQ应用问题消息可靠性的保障 ​​​​​​​消息补偿机制 消息的幂等性保障 ​​​​​​​乐观锁解决方案 ​​​​​​​消息补偿机制这个图看起来好像很复杂，其实只做到了三件事情：发消息 收到消息确认 检查比对是不是收到消息了详细说明消息补偿流程发生业务操作，业务数据写入数据库 生产者将消息发送给MQ的队列Q1 发送了一条与step2中一摸一样的延迟消息到对了Q3 消费者监听Q1，获取到了step2中

TCC理论：分布式事务基础理论——TCCHmily介绍：分布式事务TCC方案——Hmily金融级柔性分布式事务解决方案介绍本文demo代码：GitHub依赖 <dependency> <groupId>org.dromara</groupId> <artifactId>hmily-springcloud</artifactId> <vers

关于TCC的理论部分请参考：分布式事务基础理论——TCC概述目前市面上的TCC框架众多（都是国内的呢）：框架名称 GitHub地址 tcc-transaction https://github.com/changmingxie/tcc-transaction Hmily https://github.com/dromara/hmily ByteTCC https://github.com/liuyangming/ByteTCC EasyTransactio

什么是TCC事务TCC是 try、confirm、cancel三个单词的缩写。TCC要求每个分支事务实现三个操作：预处理【try】：try是业务检查和资源预留的操作 确认【confirm】：confirm是业务确认操作 撤销【cancel】：cancel是实现一个与try相反的操作，即回滚但是我个人感觉TCC和AT实际的执行过程很相像鸭~TCC执行原理Try阶段首先在TCC中，还是存在【全局事务管理】的角色，资源1和2还是指代【事务参与者】 在TCC分布式事务执行中，【全

示例代码这里拿（仓库中msf-database服务）概述mybatis-plus作为一款优秀的mybatis插件已经得到了行业的广泛认可和使用，在mybatis-plus提供的众多功能中，有一项功能在分布式系统的构件中非常重要，那就是多数据源的支持。由于分布式系统的设计要求，需要对业务进行拆分，分表分库就自然而然变得十分常见了。但是在分表分库之后就面临一个问题：当同时需要操作的业务表分散在多个数据库中的时候，怎么保证一系列数据操作的原子性，怎么控制不同数据库之间的事务回滚呢？巧了，优秀的myba

需要了解分布式事务的同学可以关注我的专栏一起学习，欢迎沟通：分布式事务阿里开源分布式事务一站式解决方案seata基础认识可参见：分布式事务2PC协议之——Seata方案基本认识概述在我的另一篇关于seata方案的基本认识中我们了解到seata方案支持如下四种事务模式：AT TCC SAGA XA其中XA模式有较为明显的缺陷（锁定数据库资源时间长，需要本地数据库支持XA协议），较为常见的就是AT模式和TCC模式，SAGA模式由于其点特分明，需要谨慎使用。本文主要介绍一下较为经典的A..

概述Seata官网：http://seata.io/zh-cn/在前一篇文章：分布式事务2PC协议之——XA方案中，我们最后提到了XA方案存在的两个问题：需要本地数据库支持XA协议 资源锁需要等到两个阶段都完成之后才能释放，性能受影响。这两个问题在Seata方案中得以解决。Seata不要求数据库支持XA协议，只要求数据库可以完成其本地事务就可以了 对数据库资源占用时间短Seata方案是阿里中间件团队发起的开源项目Fescar，之后更名为Seata，它是一个开源的分布式事务框架。它通过

概述2PC方案是在传统数据库层面实现的，如Oracle和MySQL都支持2PC协议，为了统一标准减少在行业内不必要的对接成本，需要制定标准化的处理模型以及接口标准，国际开放标准组织Open Group定义了分布式事务处理模型DTP（Distributed Transaction Processing Reference Model）。2PC协议可以参考我的另一篇文章：分布式事务解决方案——2PC（两阶段提交）概念举栗用新用户注册送积分为例来解释一下XA方案应用程序（AP）连接用户库和

什么是2PC2PC即两阶段提交协议，2就是两阶段的意思嗷。是将整个事务流程分为两个阶段——准备阶段（Prepare phase）和提交阶段（Commit phase）。典型的2PC解决方案有XA方案和案例的Seata方案。举栗说明张三和李四要去AA制吃单位食堂，只有都掏钱了，老板才给他们饭票，只有其中一个人掏钱，老板是不给他们饭票的。准备阶段：张三付款，李四付款。 提交阶段：老板核算最终金额，发票。 如果其中一个人不付款，老板是不会他们饭票的，并且会退还另一个人的钱整个事务的过程由

概述CAP理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）中的两个，其实在实际应用中AP最多，舍弃一致性，保证可用性和分区容忍性。但是在实际业务场景中很多时候也要实现“一致性”，这总一致和CAP中的一致性不同，CAP中的一致性是一种强一致性，实际业务场景中往往采用的是最终一致性，其允许在一定时间内不同节点之间的数据不一致现象的存在，但是必须保证在一定时间之后的每个节点数据必须是一致的，强调

CAP理论全称：Consistency & Availability & Partition tolerance，分别是一致性、可用性、分区容忍性，这是分布式架构当中最基础的理论。以电商场景为案例帮助我们理解概念：这是一个典型的读写分离场景Consistency 一致性是指写操作后的读操作可以读取到最新的数据，当数据分布在多个节点，从任意节点读取的到的数据都是最新的。以上图为例，商品信息如果需要做一致性保证的话，就要做满足如下要求：商品服务写入主数据库成功，向