Springboot2.0新教程（9）

测试用，Springboot2.0教程（1）

系统结构

RPC系统结构：

+----------+     +----------+| Consumer | <=> | Provider |+----------+     +----------+
Consumer调用的Provider提供的服务。

Message Queue系统结构：

+--------+     +-------+     +----------+| Sender | <=> | Queue | <=> | Receiver |+--------+     +-------+     +----------+
Sender发送消息给Queue；Receiver从Queue拿到消息来处理。

功能特点

在架构上，RPC和Message的差异点是，Message有一个中间结点Message Queue，可以把消息存储。

通过以上4步完成了一个消息事务。对于以上的4个步骤，每个步骤都可能产生错误，下面一一分析：

• 步骤一出错，则整个事务失败，不会执行A的本地操作
• 步骤二出错，则整个事务失败，不会执行A的本地操作
• 步骤三出错，这时候需要回滚预备消息，怎么回滚？答案是A系统实现一个消息中间件的回调接口，消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息
• 步骤四出错，这时候A的本地事务是成功的，那么消息中间件要回滚A吗？答案是不需要，其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务

基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作，其中B系统的操作由消息驱动，只要消息事务成功，那么A操作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地操作，如果本地操作失

是无意义这是无意

前言

设计一个分布式事务框架前，首先要明确问题到定义。分析具体应用场景，包括以下三个：A、服务内跨数据库的事务；B、跨内部服务的事务；C、跨外部服务的事务。其中划分内部和外部的标准是：内部服务我们可以控制其实现，修改配置或代码；外部服务指的是第三方的，只能约定通信的方式和具体协议，具体代码实现在控制范围之外。

一、应用场景A：服务内跨数据库

如下图所示，在同一个服务方法内，访问两个或两个以上数据库。我们知道，Java事务是通过Connection对象控制的。不同的数据库，是不同的数据库链接，通过不同的Connection对象实现。传统数据库事务无法实现事务控制，需要引入事务协调者的概念。这是场景A，这个场景中分布式体现在数据库的部署上。