spring boot 整合rabbitmq

最新推荐文章于 2024-08-12 00:09:38 发布

LQQ一直都在改变

最新推荐文章于 2024-08-12 00:09:38 发布

阅读量173

点赞数

本文链接：https://blog.csdn.net/weixin_39878226/article/details/107226996

版权

spring boot的环境怎么搭建这边就不提了，这里引入spring boot -AMQP的依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
 </dependency>

配置连接,创建交换机，队列
首先我和上面一样先要配置连接信息这里可以选用yml的方式也可以选用javaConﬁg的方式这里两种方式我都贴出来你们自己选
yml：参数什么意思刚刚介绍过了这里吧你自己的参数填进去就好了

spring:
  rabbitmq:
    host:
    port:
    username:
    password:
    virtual-host:

这样 spring boot 会帮你把rabbitmq其他相关的东西都自动装备好，

javaConﬁg：

@Bean
public ConnectionFactory connectionFactory() {
    CachingConnectionFactory connectionFactory = new CachingConnectionFactory("localhost",5672);                                                                   
    //我这里直接在构造方法传入了
    //        connectionFactory.setHost();
    //        connectionFactory.setPort();
    connectionFactory.setUsername("admin");
    connectionFactory.setPassword("admin");                            
    connectionFactory.setVirtualHost("testhost");
    //是否开启消息确认机制
    //connectionFactory.setPublisherConfirms(true);
    return connectionFactory; 
}

配置完连接之后我们就可以开始发送消息和接收消息了（因为我们上面刚刚测试rabbitmq的时候创建过队列和交换机等等这种东西了当然 spring boot也可以创建）
spring boot创建交换机队列并绑定：

@Bean
public DirectExchange  defaultExchange() {
    return new DirectExchange("directExchange"); 
}
 
@Bean 
public Queue queue() {
    //名字  是否持久化
    return new Queue("testQueue", true);
}
 
@Bean 
public Binding binding() {
    //绑定一个队列  to: 绑定到哪个交换机上面 with：绑定的路由建（routingKey）
    return BindingBuilder.bind(queue()).to(defaultExchange()).with("direct.key"); 
}

发送消息: 发送消息比较简单， spring 提供了一个RabbitTemplate 来帮助我们完成发送消息的操作如果想对于RabbitTemplate 这个类进行一些配置（至于有哪些配置我们后面会讲到）我们可以在conﬁg类中吧他作为Bean new出来并配置

@Bean 
public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) {
    //注意  这个ConnectionFactory 是使用javaconfig方式配置连接的时候才需要传入的  如果是yml配置 的连接的话是不需要的    
    RabbitTemplate template = new RabbitTemplate(connectionFactory);    
    return template; 
}

@Component 
public class TestSend {
 
    @Autowired    RabbitTemplate rabbitTemplate;
 
    public void testSend() {
        //至于为什么调用这个API 后面会解释
        //参数介绍： 交换机名字，路由建， 消息内容                    
        rabbitTemplate.convertAndSend("directExchange", "direct.key", "hello");
    }
 }

我们只需要写一个类然后交给spring 管理在类里面注入RabbitTemplate 就可以直接调用api来发送消息了
接受消息：
这里我新建了一个项目（最好新建一个当然不新建也没关系）来接收信息（之前的配置这里就不贴出来了和上面基本一样）

@Component 
public class TestListener  {
 
 @RabbitListener(queues = "testQueue")    
 public void get(String message) throws Exception{
        System.out.println(message);    
 }
 
}

不出意外的话运行起来能看见效果，这里就不贴效果图了那么至此rabbitmq的一个快速开始以及和spring boot整合就完毕了，下面开始会讲一些rabbitmq的一些高级特性以及原理等

RabbitMq特性
如何确保消息一定发送到Rabbitmq了？

我们刚刚所讲过的例子在正常情况下是没问题的，但是实际开发中我们往往要考虑一些非正常的情况，我们从消息的发送开始：
默认情况下，我们不知道我们的消息到底有没有发送到rabbitmq当中，这肯定是不可取的，假设我们是一个电商项目的话用户下了订单订单发送消息给库存结果这个消息没发送到rabbitmq当中但是订单还是下了，这时候因为没有消息库存不会去减少库存，这种问题是非常严重的，所以接下来就讲一种解决方案：失败回调
失败回调，顾名思义就是消息发送失败的时候会调用我们事先准备好的回调函数，并且把失败的消息和失败原因等返回过来。
具体操作：
注意使用失败回调也需要开启发送方确认模式开启方式在下文更改RabbitmqTemplate：

@Bean 
public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) {            
    RabbitTemplate template = new RabbitTemplate(connectionFactory);
    //开启mandatory模式（开启失败回调）
    template.setMandatory(true);
    //指定失败回调接口的实现类
    template.setReturnCallback(new MyReturnCallback());
    return template;
 }

回调接口的实现类：
实现RabbitTemplate.ReturnCallback里面的returnedMessage方法即可他会吧相关的参数都传给你

public class MyReturnCallback implements RabbitTemplate.ReturnCallback {
 
    @Override
    public void returnedMessage(Message message, int replyCode, String replyText, String         
        exchange, String routingKey) {
        System.out.println(message);
        System.out.println(replyCode);
        System.out.println(replyText);
        System.out.println(exchange);
        System.out.println(routingKey);
    }
 }

这里模拟一个失败的发送：当指定的交换机不能吧消息路由到队列时（没有指定路由建或者指定的路右键没有绑定对应的队列或者压根就没有绑定队列都会失败）消息就会发送失败效果:

分别打印的是错误状态码，错误原因（这里的原因是不能路由）交换机名字和路由建（还有个参数是你发送出去的消息因为太长了就没截图了.）
可能有些同学想到了一个答案------事物
没错事物的确能解决这个问题，而且恰巧rabbitmq刚好也支持事物，但是！事物非常影响rabbitmq的性能有多严重？据我所查到的资料（当然只是我所了解的同学们也可以自己去尝试测试结果）开启rabbitmq事物的话对性能的影响超过100倍之多也就是说开启事物后处理一条消息的时间不开事物能处理100条（姑且这样认为吧），那么这样是非常不合理的，因为消息中间件的性能其实非常关键的（参考双11）如果这样子做的话虽然能确保消息100%投递成功但是代价太大了！
那么除了事物还有什么解决方案吗？
rabbitmq其实还提供了一种解决方案，叫:发送方确认模式这种方式对性能的影响非常小而且也能确定消息是否发送成功
而且发送方确认模式一般也会和失败回调一起使用这样就能确保消息100%投递了
发送方确认开启: 其实代码在上面配置连接的时候已经放出来了就是在连接工厂那被注释的一行代码：

 connectionFactory.setPublisherConfirms(true);

如果是yml配置的话：

spring:
  rabbitmq:
    publisher-confirms: true

和失败回调一样实现一个接口:

public class MyConfirmCallback implements RabbitTemplate.ConfirmCallback{
 
    @Override
    public void confirm(CorrelationData correlationData, boolean ack, String cause) {
        System.out.println(correlationData);
        System.out.println(ack);
        System.out.println(cause);
    }
 }

在RabbitmqTemplate 设置一下

template.setConfirmCallback(new MyConfirmCallback());

而且我们可以在发送消息的时候附带一个CorrelationData参数这个对象可以设置一个id，可以是你的业务id 方便进行对应的操作

CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString()); 
rabbitTemplate.convertAndSend("directExchange","direct.key123123","hello",correlationData);

效果：

这里会吧我们传入的那个业务id 以及ack（是否发送成功）以及原因返回回来但是要注意的是 conﬁrm模式的发送成功的意思是发送到RabbitMq（Broker）成功而不是发送到队列成功所以才有了上面我所说的那句要和失败回调结合使用这样才能确认消息投递成功了
可能这里有点绕，简单的总结一下就是 conﬁrm机制是确认我们的消息是否投递到了 RabbitMq（Broker）上面而mandatory是在我们的消息进入队列失败时候不会被遗弃（让我们自己进行处理）

那么上面就是rabbitmq在发送消息时我们可以做的一些处理，接下来我们会讲到rabbitmq在接收（消费）消息时的一些特性

Rabbitmq消费端实战
消费者如何确认消费？

为什么要确认消费？默认情况下消费者在拿到rabbitmq的消息时已经自动确认这条消息已经消费了，讲白话就是rabbitmq的队列里就会删除这条消息了，但是我们实际开发中难免会遇到这种情况，比如说拿到这条消息发现我处理不了比如说参数不对，又比如说我当前这个系统出问题了，暂时不能处理这个消息，但是这个消息已经被你消费掉了 rabbitmq的队列里也删除掉了，你自己这边又处理不了，那么，这个消息就被遗弃了。这种情况在实际开发中是不合理的， rabbitmq提供了解决这个问题的方案，也就是我们上面所说的conﬁrm模式只是我们刚刚讲的是发送方的这次我们来讲消费方的。

首先我们在消费者这边（再强调一遍我这里建议大家消费者和生产者分两个项目来做，包括我自己就是这样的，虽然一个项目也可以，我觉得分开的话容易理解一点）
设置一下消息确认为手动确认: 当然我们要对我们的消费者监听器进行一定的配置的话，我们需要先实例一个监听器的Container 也就是容器，那么我们的监听器（一个消费者里面可以实例多个监听器）可以指定这个容器那么我们只需要对这个 Container（容器）进行配置就可以了
首先得声明一个容器并且在容器里面指定消息确认为手动确认:

@Bean 
public SimpleRabbitListenerContainerFactory simpleRabbitListenerContainerFactory(ConnectionFactory connectionFactory){
     SimpleRabbitListenerContainerFactory simpleRabbitListenerContainerFactory =
            new SimpleRabbitListenerContainerFactory();
    //这个connectionFactory就是我们自己配置的连接工厂直接注入进来
     simpleRabbitListenerContainerFactory.setConnectionFactory(connectionFactory);
    //这边设置消息确认方式由自动确认变为手动确认
     simpleRabbitListenerContainerFactory.setAcknowledgeMode(AcknowledgeMode.MANUAL);
     return simpleRabbitListenerContainerFactory;
 }

AcknowledgeMode关于这个类就是一个简单的枚举类我们来看看：

3个状态不确认手动确认自动确认

我们刚刚配置的就是中间那个手动确认

既然现在是手动确认了那么我们在处理完这条消息之后得使这条消息确认：

@Component 
public class TestListener  {
     //containerFactory:指定我们刚刚配置的容器 
    @RabbitListener(queues = "testQueue",containerFactory
             ="simpleRabbitListenerContainerFactory")
    public void getMessage(Message message, Channel channel) throws Exception{
        System.out.println(new String(message.getBody(),"UTF-8"));
        System.out.println(message.getBody());
        //这里我们调用了一个下单方法  如果下单成功了 那么这条消息就可以确认被消费了
        boolean f =placeAnOrder();
        if (f){
            //传入这条消息的标识， 这个标识由rabbitmq来维护 我们只需要从message中拿出来就可以
            //第二个boolean参数指定是不是批量处理的 什么是批量处理我们待会儿会讲到
            channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        }else {
            /**当然 如果这个订单处理失败了  我们也需要告诉rabbitmq 告诉他这条消息处理失败了 可以退回 也可以遗弃 要注意的是 无论这条消息成功与否  一定要通知 就算失败了 如果不通知的话 rabbitmq端会显示这条 消息一直处于未确认状态，那么这条消息就会一直堆积在rabbitmq端 除非与rabbitmq断开连接 那么他就会把这条 消息重新发给别人  所以 一定要记得通知！*/
            //前两个参数 和上面的意义一样， 最后一个参数 就是这条消息是返回到原队列 还是这条消息作废 就是不退回了。
                    
            channel.basicNack(message.getMessageProperties().getDeliveryTag(),false,true);
            //其实 这个API也可以去告诉rabbitmq这条消息失败了  与basicNack不同之处 就是 他不能批
            //量 处理消息结果 只能处理单条消息   其实basicNack作为basicReject的扩展开发出来的
            //channel.basicReject(message.getMessageProperties().getDeliveryTag(),true);
        }
    }
}

正常情况下的效果，我就不演示给大家看了，这里给大家看一个如果忘记退回消息的效果:
这里我把消息确认的代码注释掉:

//            channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);

然后调用生产者发送一条消息我们来看管理页面：

这里能看到有一条消息在rabbitmq当中而且状态是ready 然后我们使用消费者来消费掉他注意这里我们故意没有告诉rabbitmq我们消费成功了来看看效果
这里消费的结果打印就不截图了还是来看管理页面：

就算我们消费端消费了下次但是能看到这条消息还是会在rabbitmq当中只是他的状态为 unacked 就是未确认这就是我们刚刚说的那种情况无论消费成功与否一定要通知rabbitmq 不然就会这样一直囤积在rabbitmq当中直到连接断开为止.

消息预取

扯完消息确认我们来讲一下刚刚所说的批量处理的问题
什么情况下回遇到批量处理的问题呢？
在这里就要先扯一下rabbitmq的消息发放机制了
rabbitmq 默认他会最快以轮询的机制吧队列所有的消息发送给所有客户端（如果消息没确认的话他会添加一个 Unacked的标识上图已经看过了）那么这种机制会有什么问题呢，对于Rabbitmq来讲这样子能最快速的使自己不会囤积消息而对性能造成影响，但是对于我们整个系统来讲，这种机制会带来很多问题，比如说我一个队列有2个人同时在消费，而且他们处理能力不同，我打个最简单的比方有100个订单消息需要处理（消费）现在有消费者A 和消费者B ，消费者A消费一条消息的速度是 10ms 消费者B 消费一条消息的速度是15ms （当然这里只是打比方）那么 rabbitmq 会默认给消费者A B 一人50条消息让他们消费但是消费者A 他500ms 就可以消费完所有的消息并且处于空闲状态而消费者B需要750ms 才能消费完如果从性能上来考虑的话这100条消息消费完的时间一共是750ms（因为2个人同时在消费）但是如果在消费者A消费完的时候能把这个空闲的性能用来和B一起消费剩下的信息的话，那么这处理速度就会快非常多。
这个例子可能有点抽象，我们通过代码来演示一下
我往Rabbitmq生产100条消息由2个消费者来消费其中我们让一个消费者在消费的时候休眠0.5秒（模拟处理业务的延迟）另外一个消费者正常消费我们来看看效果：

正常的那个消费者会一瞬间吧所有消息（50条）全部消费完（因为我们计算机处理速度非常快）下图是加了延迟的消费者

可能我笔记里面你看不出效果，这个你自己测试就会发现其中一个消费者很快就处理完自己的消息了另外一个消费者还在慢慢的处理其实这样严重影响了我们的性能了。其实讲了这么多那如何来解决这个问题呢？
我刚刚解释过了造成这个原因的根本就是rabbitmq消息的发放机制导致的，那么我们现在来讲一下解决方案: 消息预取
什么是消息预取？讲白了以前是rabbitmq一股脑吧所有消息都均发给所有的消费者（不管你受不受得了）而现在是在我消费者消费之前先告诉rabbitmq 我一次能消费多少数据等我消费完了之后告诉rabbitmq rabbitmq再给我发送数据
在代码中如何体现？
在使用消息预取前要注意一定要设置为手动确认消息，原因参考上面划重点的那句话。因为我们刚刚设置过了这里就不贴代码了，完了之后设置一下我们预取消息的数量一样是在容器（Container）里面设置：

@Bean 
public SimpleRabbitListenerContainerFactory simpleRabbitListenerContainerFactory(ConnectionFactory connectionFactory){
    SimpleRabbitListenerContainerFactory simpleRabbitListenerContainerFactory =
            new SimpleRabbitListenerContainerFactory();
    simpleRabbitListenerContainerFactory.setConnectionFactory(connectionFactory);
    //手动确认消息
    simpleRabbitListenerContainerFactory.setAcknowledgeMode(AcknowledgeMode.MANUAL);
    //设置消息预取的数量
    simpleRabbitListenerContainerFactory.setPrefetchCount(1);
    return simpleRabbitListenerContainerFactory;
 }

那么设置完之后是什么效果呢？还是刚刚那个例子还是2个消费者因为会在消费者返回消息的确认之后 rabbitmq 才会继续发送消息给客户端而且客户端的消息累计量不会超过我们刚刚设置预取的数量，所以我们再运行同样的例子的话会发现 A消费者消费完99条消息了 B消费者才消费1条（因为B消费者休眠了0.5秒才消费完{返回消息确认} 但是0.5秒之内A消费者就已经把所有消息消费完毕了当然如果计算机处理速度较慢这个结果可能会有差异,效果大概就是A消费者会处理大量消息）

我这里的效果就是B消费者只消费一条消息 A消费者就消费完了，效果图就不发了这里同学们尽量自己测试一下或者改变一下参数看看效果。
关于这个预取的数量如何设置呢？我们发现如果设置为1 能极大的利用客户端的性能（我消费完了就可以赶紧消费下一条不会导致忙的很忙闲的很闲）但是，我们每消费一条消息就要通知一次rabbitmq 然后再取出新的消息，这样对于rabbitmq的性能来讲是非常不合理的所以这个参数要根据业务情况设置

我根据我查阅到的资料然后加以测试，这个数值的大小与性能成正比但是有上限，与数据可靠性，以及我们刚刚所说的客户端的利用率成反比大概如下图：

那么批量确认，就是对于我们预取的消息，进行统一的确认。

死信交换机

我们来看一段代码:

channel.basicNack(message.getMessageProperties().getDeliveryTag(),false,true);

我们上面解释过这个代码是消息处理失败的确认然后第三个参数我有解释过是消息是否返回到原队列，那么问题来了，如果没有返回给原队列那么这条消息就被作废了？

rabbitmq考虑到了这个问题提供了解决方案：死信交换机(有些人可能叫作垃圾回收器,垃圾交换机等)
死信交换机有什么用呢？在创建队列的时候可以给这个队列附带一个交换机，那么这个队列作废的消息就会被重新发到附带的交换机，然后让这个交换机重新路由这条消息
理论是这样，代码如下：

    @Bean    
    public Queue queue() {
        Map<String,Object> map = new HashMap<>();
        //设置消息的过期时间 单位毫秒
        map.put("x-message-ttl",10000);
        //设置附带的死信交换机
        map.put("x-dead-letter-exchange","exchange.dlx");
        //指定重定向的路由建 消息作废之后可以决定需不需要更改他的路由建 如果需要 就在这里指定
        map.put("x-dead-letter-routing-key","dead.order");
        return new Queue("testQueue", true,false,false,map);
    }

大概是这样的一个效果：