rabbitMQ 中三种常用交换机:direct、topic、fanout的使用以及区别和queue消息的Ack,Nack ,Reject 消息类型

简单模式
生产者,一个队列一个或多个消费者,当多个消费者同时监听一个队列时,他们并不能同时消费一条消息,而是随机消费消息,即一个队列中一条消息,只能被一个消费者消费。

订阅与发布模式(fanout)
生产者,一个交换机(fanoutExchange),没有路由规则,多个队列,多个消费者。生产者将消息不是直接发送到队列,而是发送到X交换机,然后由交换机发送给两个队列,两个消费者各自监听一个队列,来消费消息。

路由模式(direct)
生产者,一个交换机(directExchange),路由规则,多个队列,多个消费者。主要根据定义的路由规则决定消息往哪个队列发送。

主题模式(topic)
生产者,一个交换机(topicExchange),模糊匹配路由规则,多个队列,多个消费者。

                                                                订阅模式-headers
不依赖于routing key与binding key的匹配规则来路由消息,而是根据发送的消息内容中的headers属性进行匹配。 在绑定Queue与Exchange时指定一组键值对;当消息发送到Exchange时,RabbitMQ会取到该消息的headers(也是一个键值对的形式),对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键值对;如果完全匹配则消息会路由到该Queue,否则不会路由到该Queue。

RPC模式

MQ本身是基于异步的消息处理,前面的示例中所有的生产者(P)将消息发送到RabbitMQ后不会知道消费者(C)处理成功或者失败(甚至连有没有消费者来处理这条消息都不知道)。 但实际的应用场景中,我们很可能需要一些同步处理,需要同步等待服务端将我的消息处理完成后再进行。 

对于RPC请求,客户端发送一条带有两个属性的消息:replyTo,设置为仅为请求创建的匿名独占队列,和correlationId,设置为每个请求的唯一id值。

请求被发送到rpc_queue队列。

RPC工作进程(即:服务器)在队列上等待请求。当一个请求出现时,它执行任务,并使用replyTo字段中的队列将结果发回客户机。

客户机在回应消息队列上等待数据。当消息出现时,它检查correlationId属性。如果匹配请求中的值,则向程序返回该响应数据。

总结

订阅模式,路由模式,主题模式,他们的相同点就是都使用了交换机,只不过在发送消息给队列时,添加了不同的路由规则。

订阅模式没有路由规则,路由模式为完全匹配规则,主题模式为模糊匹配(正则表达式,完全匹配规则)。

在交换机模式下:队列和路由规则有很大关系,生产者只用关心交换机与路由规则即可,无需关心队列。

消费者不管在什么模式下:永远不用关心交换机和路由规则,消费者永远只关心队列,消费者直接和队列交互。

RabbitMQ的常见队列模型,simple模式、work模式、fanout模式、direct模式、topic模式、headers模式、RPC_毅大师的博客-CSDN博客_headers模式

消息队列的高级用法: QUEUE:

1. 消息的持久化

在消费者端做限流

3 Ack和Nack 和Reject的区别

在服务器端的客户端页面从队列中获取消息是一个危险的动作,生产环境一定要了解业务之后再做操

Act Mode

  • Nack message requeue true

        获取消息,但是不做ack应答确认,消息重新入队【队列是先进先出,拿到了消息这个消息就出队列了,现在这句话就是拿到了消息,然后又重新将消息给丢到队列里面去,其他人还可以获取到】

  • Ack message requeue false

        获取消息,应答确认,消息不重新入队,将会从队列中删除

  • reject requeue true

        拒绝获取消息,消息重新入队

  • reject requeue false

        拒绝获取消息,消息不重新入队,将会被删除

Encoding
        AMQP消息负载可以包含任何的二进制内容,因此他们很难再浏览器中展示,编码的选         项含义有如下内容:string/base64,如果消息负载可以使用UTF-8字符串编码,就执行此 操作,否则就按照base64编码进行返回。

Messages
        定义一次从队列中获取的消息数量

 

  • type:此queue的类型,默认为classic 主队列,也可以设置为quorum 从队列
  • name:此queue的名称
  • durability:queue中的消息是否要持久化到硬盘
  • auto delete:如果此queue没有绑定到任何一个exchange,是否自动删除此queue
  • arguments:设置一些其它参数
  • exchange、queue的消息持久化能力,保证了rabbitmq的高可靠性。

https://www.cnblogs.com/1024llh/articles/15918851.html

消息确认可以让RabbitMQ知道消费者已经接受并处理完消息。但是如果消息本身或者消息的处理过程出现问题怎么办?需要一种机制,通知RabbitMQ,这个消息,我无法处理,请让别的消费者处理。这里就有两种机制,Reject和Nack。

1)Ack对于明确要消费的消息。可以通过Ack的方式告知mq,mq就会发送下一条消息给消费者

2)Nack 告知mq,这样的消息我不处理,丢弃掉,此时消息会成为死信。

3)Reject

reject与nack的用法相同,但是与nack只有一个区别,nack一次可以拒签多条消息(multiple:true),但是reject一次只能拒签一条消息。

死信队列

DLX(死信队列)

  • DLX定义 DLX为Dead Letter Exchange,死信队列。当一个消息在一个队列中变成死信(dead message)之后,它能重新publish到另一个Exchange,那么这个让消息变为死信的Exchange就是DLX(死信队列)。
  • 消息变成死信的几种情况 1、消息被拒绝,ack为false,并且 requeue=false; 2、消息TTL(Time To Live)过期,指消息达到了过期时间; 3、队列达到最大长度。

如果设置了死信队列,当一个普通队列中的消息成为了死信之后,于是这样的消息就会自动被publish到死信队列中。

消息什么情况下会成为死信?

1)消息被拒签,并且不会重回队列

2)消息过期了

3)超出了队列的长度,装不下的消息将会成为死信。

通过消息的过期成为死信的机制,死信队列很容易就能做出一个延迟队列的效果。

死信队列很容易就做出一个延迟队列的效果

  • 0
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值