乐百寿

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