RabbitMQ-SpringBoot配置及实现分布式事务(消费发送生产接收)

事务：一个机器上的

Service(){

​ dao1.操作;
​ dao2.操作 //比如dao1成功了修改操作成功了 dao2添加操作却失败了 事务：需要保证数据一致性
需要同时成功，或同时失败出现回滚操作

}

分布式事务：两个及其或者多个机器上

Service(){

​ service1远程
​ service2远程

}

在分布式，微服务环境下有的时候一个操作需要涉及到两个服务或多个服务进行操作，并且要求原子性的操作，这时候就需要分布式事务

方法多种

两阶段提交

就是分成两个阶段，第一阶段是服务执行完成但是没有提交。第二阶段是提交服务

引入一个中间者，在中间者里面判断是否提交或者是回滚

问题：

1、为保证安全，在执行时需要保证处于阻塞同步状态

2、网络传输中也会报错

三阶段提交

为了避免协调者和参与者同时挂掉，所以把二阶段提交中的准备阶段分成二份，变成了三阶段提交

协调者调用参与者，查看是否提交事务；

参与者接收到消息后影响可以提交

协调者根据反馈选择具体操作

缺点：一致性依旧存在

补偿事务

每一个操作都注册确认和注销操作，把操作分成三步

针对业务去执行操作

1、准备执行业务

2、对业务操作进行提交

3、业务操作失败，执行回滚

本地消息表

结合数据库把分布式事务转换成本地事务

数据库记录状态

然后使用异步请求机制不断刷新状态检测是否执行成功，可以用线程也可以用消息队列

MQ事务消息

部分消息中间件中有事务消息，或者说消息确认机制

下面的内容主要讲的是基于RabbitMQ中的消息确认机制和死信机制实现的分布式事务

消息确认机制：当消息生产者向消费者发送消息时，消费者正确接受到消息后会有回馈机制表示消费者接受到消息

死信机制：当消费者接收到消息后可以调用调用代码拒绝消息，这时候消息会进入到到对应的死信队列，死信队列进行操作就可以进行处理。

涉及到的名词

交换机 exchange ：接收消息，负责把消息发送给对应的队列

Channel：与Exchange的连接

Queue：存储消息接收者（消费者）的消息

RoutingKey：指定当前消息被谁接受

1、生产者

首先是相关配置