RabbitMQ笔记

最新推荐文章于 2024-07-12 07:00:00 发布

liangdu_Zuker

最新推荐文章于 2024-07-12 07:00:00 发布

阅读量276

点赞数

分类专栏：分布式

本文链接：https://blog.csdn.net/u010833547/article/details/88080227

版权

分布式专栏收录该内容

32 篇文章 1 订阅

订阅专栏

RabbitMQ笔记

rabbitmq中的角色可以抽象为生产者，消费者，broker，以及两条channel。三者之间通过channel进行交互。获取channel需要登陆授权的Connector。生产者的channel需要配置交换器标签和路由键标签，路由键标签最终代替queue标签，之后Producer不再与queue直接接触。而consumer的channel则需要配置好接收滑动窗口的大小，以及queue的名称，还有消息处理handler。
RabbitMQ的queue不支持广播消费（没有topic概念，如需要，需要自己封装），但是exchanger可以做到广播消息给多个队列。
RabbitMQ的架构依据是AMQP，所以最好有所了解。
Exchanger可以理解为Producer的代理，它可以把消息投递给一个或者多个队列
BindingKey的官方解释“the RoutingKey to use for Binding”, 从这句话可以理解为绑定键就是用来绑定的路由键，也就是说路有键可以分为未绑定的，和绑定过的（将exchanger和queue绑定）。之后producer就是面向bindingkey发布消息。
topic交换器可以使得bindingkey支持模糊匹配的能力，从某种意义上看，topic类型是direct类型的增强版。
exchanger由四种类型的direct,topic，fanout,headers。其中fanout就是全量广播，而topic支持模糊广播，而direct可以支持确定性广播。实际上用的最多的应该是topic，因为它的自定义功能最强大。
channel实现了对tcp连接connector的复用。减少了网络IO的开销。它是AMQP提出的概念。
AMQP协议是基于TCP协议之上的应用层协议，它的握手和关闭页TCP一样是稳定可靠保守的通讯协议，性能也相对低。（比如一样拥有滑动窗口机制）
AMQP协议中每次deliver都需要一个ack

#### 学习完AMQP的总结：
它是一个稳定可以靠的同学协议，它的角色是客户端和broker服务器，它的操作对象是消息，队列，交换器，连接，channel配置，事务，confirm机制配置。事务是同步耗性能的，confirm是异步高性能的。

channel是非线程安全的，但是它的isopen（）方法是同步安全的，不过代价很大，它使用了syntronized关键字。
交换器可以自由组合
声明队列排他性是关键词：首次创建的连接可见，关闭连接后自动删除。
自动删除的定义是，至少被消费者连接过一次，之后不再有任何client连接，就会被删除。
basic.consume是异步的比basic.get的吞吐量高很多。
如果消费者没有ack时挂掉，消息会马上回到重新分发队列，如果消费者连接没有断开，这个消息会一直处于待确认状态。
basic.recover默认会重新分发消息给与之前不同的消费者处理。
mandatory 为true，无队列的消息会返回给producer的returnlistener处理。
如果没有队列接受的消息，不想丢失，也不想返回，可以交给备胎交换器alternate-exchanger处理。
备胎交换器的优先级 > mandatory > policy（rabbitmqctl set_policy ）
备胎交换器丢失的信息无任何异常日志。
可以给队列所有方法设置相同的秒级过期时间TTL，过期的消息会定义被清除。也可以对单个消息设置毫秒级TTL，过期时延迟到即将投递之前判断是否过期抛弃（这种延迟删除有点类似delayQueue的实现），如果两种都设置了，则取最短的TTL为准。
ttl为0则表示消息马上投递给消费者，无消费者则给备胎exchanger或returnlistener或policy（过期）。
队列的生命也可以设置TTL，不过rabbitmq重启后队列过期时间重新计算。
死信邮箱DLX可以接受被拒绝，过期，队满时抛弃的消息。是重要的优化工具。（TTL+DLX）
可以利用TTL+DLX死信邮箱机制模拟实现延迟队列，延迟队列是调度器线程池的核心工具。但是死信队列没有优先级，所以不同TTL的消息要放到不同的队列，又或者给队列和消息设置优先级。
生产者的可靠发布，可以通过同步事务和异步确认来实现，如果异步确认采用waitforconfirm性能会退化接近同步事务。而较为常见的手段有批量同步confirm,和异步批量confirm.
如果rabbitmq服务器在接受消息时出现异常就会返回给客户端basic.nack命令要求重发。
在批量模式下，出现nack是很耗性能的事，因为它会要求这批消息重发。这个模式下批量发生的条数是由rabbitmq服务器设置的。
在rabbitmq当中，Qos的滑动窗口大小中的global参数的含义：false表示，对针对每个接下来创建的consumer设置窗口，true表示该针对channel设置窗口大小。
任何一个环境都可能会导致消息乱序，要确保有序只有一个方案，就是要求消息到处理前重排序，获取只处理期望得到的需要的消息，类似新增自定义滑动窗口。
Rabbitmq确保消息至少被消费一次的方法是：
1.生产者采用confirm模式（或者事务模式）
2.采用死信队列和备胎交换器
3.broker持久化
4.consumer采用手动确认
目前所有MQ都无法保证消息能去重，最多只能确保不丢失。
一台服务器上的rabbitmq应用程序是支持多租户vhost的，默认是/
connector共享和queue的轮训是rabbitmq的性能瓶颈之一