咱们今天再来进一步学习一下 RabbitMQ 的知识点,整理了如下相关知识点
不同交换机有不同交换机的特性
适合发布订阅式,广播的方式来传递消息
适合路由到指定队列的传输消息
与上述交换机类似,只是多了通配符
会匹配消息的 headers,易用性较差
fanout exchange 可以做成备份的交换机,因为 fanout 的消息是广播的方式
若A生产者A消息发送到A交换机,路由到A队列,若A消息填写的路由 key 与 A队列的绑定 key 不对齐,则会被重新发送到 另外一个备份 fanout 交换机上
x-message-ttl
(单位毫秒)设置,队列中所有消息都有相同的过期时间若两种方式一起使用,则消息的TTL以两者之间较小的那个数值为准
消息在队列中的生存时间一旦超过设置的TTL值时,就会变成死信,消费者将无法再收到该消息
另外对于TTL 的 2 种情况:
通过队列属性x-expires
可以控制队列被自动删除前处于未使用状态的时间,未使用状态的时间 有如下含义:
当消息在一个队列中变成死信之后,它能重新被发送到另一个交换机中,这个交换机就是 死信交换机,绑定死信交换机 的队列就称之为死信队列
消息变成死信有这几种情况:
这个 死信交换机,也是一个正常的交换机
可以被任何一个队列指定,被指定成死信交换机的时候,会设置 x-dead-letter-exchange
属性,并且会设置对应的路由键 x-dead-letter-routing-key
消息不能够被消费者正确消费而被置入死信队列中的情况,后续分析程序可以通过消费这个死信队列中的内容来分析当时所遇到的异常情况,进而可以改善和优化系统
消息发送到队列之后,并不期望消费者能马上消费,也是延迟一段时间之后,才拿到该消息进行消费。
延迟队列我们是使用 死信队列 和 TTL 来模拟 延迟队列的
延迟队列使用的场景举个栗子:
本例子中,用户下单,将消息丢入队列中,TTL 为15分钟,若15还未完成支付,则消息会被丢入对应的 死信队列中进行处理
指的是 具有高优先级的队列具有最高的优先权,优先级高的消息具备优先被消费的特权
可以通过 设置 x-max-priority
来设置 优先级队列
当然,如果在消费者的消费速度远大于生产者的速度,且 Broker 没有消息堆积的情况下,对发送的消息设置优先级没有什么实际意义,因为生产者生产的消息,都能很快的被消费者立刻消灭掉
为了提高 RabbitMQ 的可靠性,RabbitMQ 做了持久化,持久化有这三部分:
RabbitMQ服务重启,若交换机不设置持久化,交换机的元数据会丢失,消息不会丢失,不过消息再也不能发送到这个交换机中了
RabbitMQ服务重启,若队列不设置持久化,元数据会丢失,数据也会丢失
设置所有的消息持久化,可靠性会大大提高,可是对于性能上是一个巨大的影响,这是一个可靠性和吞吐量之间做一个权衡
消息的传输保障,对于一般的消息中间件来说,会考虑这三个层级
消息可能会丢失,但不会重复
其中最多一次投递实现需要考虑以下几个方面的内容:
消息可能会重复,但不会丢失
生产者随意发送,消费者随意消费
每条消息一定只会被传输一次
RabbitMQ 这边 支持最多一次和至少一次
恰好一次是 RabbitMQ 无法保障的,会有这样几个原因
RabbitMQ 中的生产者确认机制有 两种模式
事务模式性能非常低,不建议使用。
事务机制在一条消息发送之后会使发送端阻塞,以等待RabbitMQ的回应,之后才能继续放下一条消息,这种方式会影响性能,所以不建议使用
发送方确认机制最大的好处在于它是异步的,一旦发布一条消息,生产者就可以在等信道返回确认的同时继续发送下一条消息
当消息最终得到确认之后,生产者便可以通过回调方式来处理该确认消息,哪怕是 RabbitMQ 自己内部出现了错误,也会回复响应的应答给到生产者 例如Nack
消费者正常启动程序之后,会是推模式
在消费者程序第一次起来的时候,是拉模式
参考资料:
RabbitMQ Tutorials
朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力
好了,本次就到这里
技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。
我是小魔童哪吒,欢迎点赞关注收藏,下次见~