乐百寿

RabbitMQ消息确认机制是为了保证消息不丢失，可靠抵达，可以使用事务消息，性能下降250倍，为此引入确认机制 • publisher confirmCallback 确认模式 • publisher returnCallback 未投递到 queue 退回模式 • consumer ack机制 一，发送端确认模式 confirmCallback； 1，开启发送端确认模式：• spring.rabbitmq.publisher-confirms=true 或者 在创建 connectionFacto

一，界面总览： 二，新建用户： 三，创建v-host 四，创建队列 五，mq的架构图： 六，RibbitMq支持的模式：

1，异步处理 2，服务解耦 3，流量削峰

RabbitMq的动态路由模式-Topic： 动态路由模式其实就是routing路由模式的一个升级，在路由模式的基础之上增加了routingKey的匹配规则，因为路由模式的routingKey都是直接写死的，如果日后有很多routingKey那么代码就要写多少，造成代码冗余，可维护度不高，那么动态路由就可以解决这一点了，通过#，*等统配符来匹配一定规则的routingKey，实现队列与交换机的绑定 实现步骤： 第一步：项目准备 消息生产方： zt-frank-mq-prod-service-9501 消

RabbitMq的路由模式-Direct： 在广播模式下一条消息可以被所有的服务进行消费，但是有的时候，我们希望不通的消息被不同的队列消费，这个时候就需要用到driect的exchange了 实现步骤： 第一步：项目准备 消息生产方： zt-frank-mq-prod-service-9501 消息消费方1：zt-frank-mq-consumer1-service-9505 消息消费方2：zt-frank-mq-consumer2-service-9506 第二步：消息生产者9501代码编写，向d

RabbitMq的广播模式： 生产者生产的消息,可被多个消费者拿到，也就是一条消息可被多个消费者消费； 特点： 每个消费者有自己的队列； 每个队列绑定到一个exchange(交换机)上 生产者只能往交换机上发送消息，而消息到底要发送给谁就不由生产者决定了，而是由交换机决定 实现步骤： 第一步：服务准备 消息生产方： zt-frank-mq-prod-service-9501 消息消费方1：zt-frank-mq-consumer1-service-9505 消息消费方2：zt-frank-mq-

WorkQueue(工作模式) 第一种模式是一对一的队列模式；当生产者的生产速度远远大于消费者的消费速度，就会使消费堆积一直处在队列之中，不能被及时的消费；所以WorkQueue模式就可以解决这一点，一个生产者对应多个消费者，与队列模式相同的时也是直接往队列里面发送消息，只不过消费的人有之前的一个变为了多个； 实现步骤： 第一步：springboot+rabbitMq的服务准备： 消息生产方： zt-frank-mq-prod-service-9501 消息消费方1：zt-frank-mq-consum

一，rabbitmq与springboot的整合 第一步：引入相关的pom依赖 <!-- RabbitMq的依赖 --> <dependency> <groupId>com.rabbitmq</groupId> <artifactId>amqp-client</artifactId> <version>5.7.2</version> </dependency> <!-- Rab