RabbitMQ实战应用技巧

1. RabbitMQ实战应用技巧

1.1. 前言

由于项目原因,之后会和RabbitMQ比较多的打交道,所以让我们来好好整理下RabbitMQ的应用实战技巧,尽量避免日后的采坑

1.2. 概述

RabbitMQ有几个重要的概念:虚拟主机,交换机,队列和绑定

  • 虚拟主机:一个虚拟主机持有一组交换机、队列和绑定,我们可以从虚拟主机层面的颗粒度进行权限控制
  • 交换机:Exchange用于转发消息,它并不存储消息,如果没有Queue队列绑定到Exchange,它会直接丢弃掉生产者发来的数据。
    交换机还有个关联的重要概念:路由键,消息转发到哪个队列根据路由键决定
  • 绑定:就是绑定交换机和队列,它是多对多的关系,也就是说多个交换机可以绑同一个队列,也可以一个交换机绑多个队列

1.3. 交换机

交换机有四种类型的模式Direct, topic, Headers and Fanout

1.3.1. Direct Exchage

Direct模式使用的是RabbitMQ的默认交换机,也是最简单的模式,适合比较简单的场景

如下图所示,使用Direct模式,我们需要创建不同的队列,而默认交换机则通过Routing key路由键的值来决定转发到哪个队列,可以看到,路由键绑定队列是可以指定多个的

1.3.2. Topic Exchange

Topic模式主要是根据通配符匹配,也就类似于模糊匹配,当这种匹配模式和路由键匹配后交换机就能转发消息到指定队列

  • 路由键为一串字符串,由句号(.)隔开,比如a.b.c
  • *)代表指定位置一个单词,(#)代表零个或者多个单词,比如a.*.b.#,表示a和b中间随意填个单词,b后面可以跟n个单词,比如a.x.b.c.d.e

Topic模式和Direct模式的区别在于交换机需要自己指定,路由键支持模糊匹配,例如:

rabbitTemplate.convertAndSend("topicExchange","a.x.b.d", " hello world!");

1.3.3. Headers Exchage

Headers也是根据规则匹配,但它不是根据路由键了,headers有个自定义匹配规则,它将匹配键值设在了消息的headers属性上,当这些键值对有一对或者全部匹配时,消息才会被投递到对应队列,这种模式效率相对较低,一般不推荐使用

1.3.4. Fanout Exchange

Fanout即为大名鼎鼎的广播模式了,它不需要管路由键,会把消息发给绑定它的全部队列,就算配置了路由键也会被忽略

1.4. 复杂情况

  1. 首先我们Direct模式,一个生产者一个消费者的情况,也就对应了一个发送者和一个队列A接收,这是没有疑问的,发送什么接收什么
  2. 当Direct模式,一个生产者发消息,开启多个消费者也就是多个相同queue,此时消息由多个消费者均匀分摊,不会重复消费(前提ack正常)
  3. 当Topic模式,一个交换机绑定两个队列,路由键有重叠关系,如下代码,此时指定路由键topic.message发送消息,队列queueMessagequeueMessages都能接收到相同消息,也就是说,topic模式可以实现类似于广播模式的形式,甚至更加灵活,它能否转发到消息由路由键决定。
  4. 相比于Fanout模式,我们如果要对消费者队列分组发送,我们需要指定不同的路由键;而Fanout模式则需要指定不同的交换机和队列绑定,实际使用结合实际情况
@Configuration
public class TopicRabbitConfig {

    final static String message = "topic.message";
    final static String messages = "topic.messages";

    @Bean
    public Queue queueMessage() {
        return new Queue(TopicRabbitConfig.message);
    }

    @Bean
    public Queue queueMessages() {
        return new Queue(TopicRabbitConfig.messages);
    }

    @Bean
    TopicExchange exchange() {
        return new TopicExchange("exchange");
    }

    @Bean
    Binding bindingExchangeMessage(Queue queueMessage, TopicExchange exchange) {
        return BindingBuilder.bind(queueMessage).to(exchange).with("topic.message");
    }

    @Bean
    Binding bindingExchangeMessages(Queue queueMessages, TopicExchange exchange) {
        return BindingBuilder.bind(queueMessages).to(exchange).with("topic.#");
    }
}

1.5. springboot配置

我们的常用配置如下

spring.rabbitmq.addresses=localhost:5672
spring.rabbitmq.username=user
spring.rabbitmq.password=123456
spring.rabbitmq.virtual-host=/
spring.rabbitmq.connection-timeout=1000
##设置监听限制:最大10,默认5
spring.rabbitmq.listener.simple.concurrency=5
spring.rabbitmq.listener.simple.max-concurrency=10
spring.rabbitmq.publisher-confirms=true
spring.rabbitmq.publisher-returns=true
spring.rabbitmq.template.mandatory=true
spring.rabbitmq.listener.simple.acknowledge-mode=manual

其中最后四条配置需要着重解释:

  • spring.rabbitmq.publisher-confirms为true,表示生产者消息发出后,MQ的broker接收到了消息,发送回执表示确认接收,不设置则可能导致消息丢失
  • spring.rabbitmq.publisher-returns为true,表示当消息不能到达MQ的Broker端,,则使用监听器对不可达的消息做后续处理,这种一般是路由键没配好,或MQ宕机才可能发生
  • spring.rabbitmq.template.mandatory当上面两个为true时,这个一定要配true,否则上面两个不起作用
  • spring.rabbitmq.listener.simple.acknowledge-mode这个为manual表示手工确认,实际生产应该设为手工,才能保证你的业务是处理完成的,注意业务的幂等性,可重复调用,手工确认代码如下例子
@Component
public class RabbitReceiver {

    @RabbitListener(bindings = @QueueBinding(
            value = @Queue(value = "queue-1",
            durable="true"),
            exchange = @Exchange(value = "exchange-1",
            durable="true",
            type= "topic",
            ignoreDeclarationExceptions = "true"),
            key = "springboot.*"
            )
    )
    @RabbitHandler
    public void onMessage(Message message, Channel channel) throws Exception {
        System.err.println("--------------------------------------");
        System.err.println("消费端Payload: " + message.getPayload());
        Long deliveryTag = (Long)message.getHeaders().get(AmqpHeaders.DELIVERY_TAG);
        //手工ACK,获取deliveryTag
        channel.basicAck(deliveryTag, false);
    }
}

1.6. 队列属性

  1. queue : 队列的名字
  2. durable : 为true表示队列中数据持久化到磁盘,可以防止mq宕机重启数据丢失
  3. exclusive : 为true表示排他性,只允许一个当前连接访问该队列,当前已连接就不允许新的连接进入否则报错,当连接断开当前队列会销毁
  4. autoDelete : 为true表示自动删除,当没有Connection连接到队列的时候,会自动删除
  5. arguments : 这个参数用来添加一些额外参数的,如下图片
    • 比如添加x-message-ttl为5000,则表示消息超过5秒没被处理就会超时过期;
    • x-expires设置120000表示队列在2分钟内没被消费则被删除;
    • x-max-length,x-max-length-bytes表示传送数据的最大长度和字节数
    • x-dead-letter-exchangex-dead-letter-routing-key表示死信交换机和死信路由,放在需要过期或处理失败的队列属性中,这些数据会转发到死信队列存储起来,创建普通的交换机和队列绑定,把交换机名填到x-dead-letter-exchange的值,填写路由键要符合死信队列的路由键
    • x-max-priority,表示设置优先级,范围为0~255,只有当消息堆积的时候,这个优先级才有意义,数字越大优先级越高
    • x-queue-mode当为lazy,表示惰性队列,3.6.0之后才被引入的概念,相比默认的模式,惰性队列模式会将生产者产生的消息直接存到磁盘中,这当然会增加IO开销,但适合应对大量消息堆积的情况;因为当大量消息堆积时,内存也不够存放,会将消息转存到磁盘,这个过程也是比较耗时且过程中不能接收新的消息。如果需要将普通队列转换成惰性队列需要将原来的队列删除,重新创建个惰性队列绑定。

1.7. 交换机属性

  1. exchange : 交换机名称
  2. type : 交换机类型
  3. durable : 持久化,同队列
  4. autoDelete : 是否自动删除,同队列
  5. internal : 若为true,表示这个exchange不可以被client用来推送消息,仅用来进行exchange和exchange之间的绑定。
  6. arguments : 额外参数,目前只有个alternate-exchange,表示当生产者发送消息到这个交换机,路由不到该交换机的队列,则会尝试这个参数指定的交换机进行路由,若路由键匹配,则路由到alternate-exchange指定的队列,相当于转发了,刚好和上一个参数internal配合,若不想本交换机起到路由队列的作用,可以设置internal为true,把消息都转发到alternate-exchange指定的交换机,由该交换机来路由指定队列,
    • 如下图:exchange0设置了alternate-exchange交换机为exchange1,生产者发送数据到exchange0路由键为test1,在exchange0路由不到,则转发到exchange1判断路由符合,发送到队列queue1

1.8. 磁盘和内存

在RabbitMQ的管理界面,当我们集群部署时可以看到Nodes节点中Info字段可能为disc也可能ram,表示了磁盘存储或内存储存。事实上,在集群部署的时候,我们至少要一个磁盘储存,它代表了将交换机,队列,绑定,用户等元数据持久化保存到磁盘,一遍重启RabbitMQ也能恢复到原先的状态,当只有一个节点时,必定是磁盘存储;而内存储存也有它的优势,就是效率更高速度更快

1.9. 报错案例

  • 当报下列错误,表示你一定存在排他性队列,也就是设置了exclusive属性的队列,由于同一个连接创建的不同通道可以访问同一个队列,此时由于这个排他属性会得到资源被锁定错误,也就是下列的错误。
  • 由此我们可以知道,若你把队列设置成了exclusive属性的,那么就别创建新的连接去访问同一个队列
ESOURCE_LOCKED - cannot obtain exclusive access to locked queue xxxxxx

今日教学视频:RabbitMQ消息队列从入门到精通,长按图片到百度云

欢迎关注公众号,一起学习进步

原文地址:https://www.cnblogs.com/sky-chen/p/11757933.html

时间: 2024-11-07 22:17:07

RabbitMQ实战应用技巧的相关文章

rabbitMQ实战(一)---------使用pika库实现hello world

rabbitMQ实战(一)---------使用pika库实现hello world 2016-05-18 23:29 本站整理 浏览(267) pika是RabbitMQ团队编写的官方Python AMQP库.需要先安装pika:pip3 install pika有较详细的注释,就不再详细说明了生产者代码:hello_world_producer.py: import pika,sys #connect to the rabbitmq,use the default vhost credent

[转]【全面解禁!真正的Expression Blend实战开发技巧】第六章 认识ListBox

反反复复考虑后,准备把这一章的切入点瞄准ListBox.并用了一个看起来有点别扭的标题“认识ListBox",许多人看到这里就不爱看了,即使是大学里用winform的学生也会说ListBox我看他好几年了.但我想说,在实际项目开发中,界面元素除了Button,另一个使用率最高的就是ListBox,你认识ListBox,但未必认识下面几种特殊的ListBox,也未必知道如何最快速构建这样特殊的ListBox,这背后还涉及了blend独有的很重要的一个元素的用法,sampledatasource!有

使用C语言调用mysql数据库编程实战以及技巧

今天编写使用C语言调用mysql数据库编程实战以及技巧.为其它IT同行作为參考,当然有错误能够留言,共同学习. 一.mysql数据库的C语言经常使用接口API 1.首先当然是链接数据库mysql_real_connect,原型例如以下: MYSQL * STDCALL mysql_real_connect( MYSQL *mysql, const char *host, const char *user, const char *passwd, const char *db, unsigned

网页设计原则理念以及实战经验技巧

(2)界面弱化 一个好的界面设计它的界面是弱化的,它突出的是功能,着重体现的是网站业提供给使用者是主要什么.这就涉及到浏览顺序.功能分区等等. 要让访客在0.5秒内就能把握网站的行业性质,1秒内就知道该从哪个地方开始使用这个网站,能点一次的,绝不点第二次.当然上面说的是大多数功能性网站,对于宣传展示性网站,诸如加特效的或Flash网站,可能就不得不花哨一些,但不能太过分.网站不是动画片,在效率越来越高,社会心理越来越浮躁的中国,人们的耐心越来越小,心理承受能力越来越低.效果可以体现意境,点到为止

[转]【全面解禁!真正的Expression Blend实战开发技巧】第八章 FluidMoveBehavior完全解析之一漂浮移动

好久没更新博客了,今天如果没急事,准备连发三篇,完全讲解Blend最牛的元素-“FluidMoveBehavior”.我向大家保证这三章一定非常精彩,不看你肯定后悔.我相信这三篇文章发表后,国内很多silverlight和wpf作品将充满各种飞出,漂浮的酷炫效果,以及让元素平滑运动的滚动条.你的客户一定会惊讶,原来软件可以这么炫.而更神奇的是,实现这些效果真的非常非常简单,一行代码都不需要写. 很多程序员不知道Blend,当然就更少人知道FluidMoveBehavior了.FluidMoveB

RabbitMQ实战:理解消息通信

本系列是「RabbitMQ实战:高效部署分布式消息队列」书籍的总结笔记. 前段时间总结完了「深入浅出MyBatis」系列,对MyBatis有了更全面和深入的了解,在掘金社区也收到了一些博友的喜欢,很高兴.另外,短暂的陪产假就要结束了,小宝也二周了,下周二就要投入工作了,希望自己尽快调整过来,加油努力. 从本篇开始总结「RabbitMQ实战」系列的阅读笔记,RabbitMQ是一个开源的消息代理和队列服务器,可以通过基本协议在完全不同的应用之间共享数据,可以将作业排队以便让分布式服务进行处理. 本篇

RabbitMQ实战:消息通信模式和最佳实践

本系列是「RabbitMQ实战:高效部署分布式消息队列」书籍的总结笔记. 通过前2篇的介绍,了解了消息通信的主要元素和交互过程,以及如何运行和管理RabbitMQ,这篇将站在开发模式的角度理解「面向消息通信」带来的好处,以及在各种场景下的最佳实践. 通过介绍,你会了解到: 面向消息通信的好处 发后即忘模型 用RabbitMQ实现RPC 面向消息通信的好处 主要从异步状态思维.处理能力扩展性.集成复杂度方面,说明面向消息通信的好处. 异步状态思维 当将消息通信集成到应用程序时,开发模式将从同步模型

RabbitMQ实战:可用性分析和实现

本系列是「RabbitMQ实战:高效部署分布式消息队列」书籍的总结笔记. 上一篇介绍了各种场景下的最佳实践,大部分场景可以使用「发后即忘」的模式,不需要响应,如果需要响应,可以使用RabbitMQ的RPC模型. RabbitMQ以异步的方式解耦系统间的关系,调用者将业务请求发送到Rabbit服务器,就可以返回了,Rabbit会确保请求被正确处理,即使遇到网络异常.Rabbit服务器崩溃.整个机房断电等特殊场景,针对这些场景,Rabbit提供了各种机制确保其可用性. 本篇通过总结可能出现的特殊场景

RabbitMQ实战:界面管理和监控

本系列是「RabbitMQ实战:高效部署分布式消息队列」书籍的总结笔记. 上一篇总结了可能出现的异常场景,并对RabbitMQ提供的可用性保证进行了分析,在出现服务器宕机后,仍然可以正常服务.另外,需要尽快恢复异常的服务器,重新加入集群,推送未消费的消息,通过监控可第一时间接收到错误并进行处理. 另外,我们想主动了解消息堆积和消费的情况,以及服务器节点的压力,RabbitMQ提供了几种方式便捷.直观的了解,包括Web管理插件.REST API.rabbitmqadmin脚本. 通过介绍,你会了解