深入理解RabbitMQ

目录

一、RabbitMQ的基本概念

二、RabbitMQ集群


一、RabbitMQ的基本概念

    RabbitMQ是一款功能丰富的传统消息队列,代表性的功能包括:消息持久化、消息确认、死信队列、消息消费端限流,丰富的功能特性是选择RabbitMQ的首要理由。RabbitMQ遵循AMQP协议,AMQP的模型如下:

 

深入理解RabbitMQ_第1张图片

    相关概念如下:1、Producer:消息生产者;2、Broker:即RabbitMQ serveice提供者;3、Virtual Host:RabbitMQ是多租户系统,一个Broker支持多个Virtual Host,这些Virtual Host之间是彼此隔离的,Virtual Host内部维护一条消息数据按照指定顺序流转的虚拟线路。4、Exchange:传输并将消息路由到0到多个队列上;5、Binding:基于routing key将消息从Exchange路由到Queue的规则;6、Queue:用于存储消息,消费者从Queue获取消费的消息;7、Connection:Producer和Consumer连接到RabbitMQ的TCP连接;8、Channel:由于TCP连接的资源开销比较大,开启多个TCP连接也让防火墙配置比较困难,AMQP协议引入了Channel来处理多连接,这些连接共用同一个TCP连接。

    AMPQ的概念中Exchange是最核心的,他负责将消息路由到正确的Queue上,目前 RabbitMQ 共四种类型:direct、fanout、topic、headers。其中headers使用的非常少,在此就不介绍了,看另外三种类型:

    direct类型:是完全匹配的单播模式,原理是比较消息中的routing key与binding中的binding-key进行比较,匹配的话将消息发送到匹配的binding-key对应队列。

    fanout类型:是广播模式,每个发送到fanout类型交换器的消息都会被投递到所有绑定到fanout交换器中的队列上。

    topic类型:是模糊匹配模式,原理是将消息中的routing key与绑定到topic类型交换器的binding-key的模式进行匹配,匹配的话将消息发送到匹配的binding-key对应队列。

详情参考官方文档:https://www.rabbitmq.com/tutorials/amqp-concepts.html#exchanges

二、RabbitMQ集群

    在生产环境中,为了高可用,几乎没有使用单机的。RabbitMQ的集群比较有特点,在正式介绍RabbitMQ集群之前,先介绍几个集群的基本概念:

    元数据:元数据是Broker上基础组件的状态和数据,基础组件包括:virtual host,Exchange,Binding。其中virtual host元数据为内部的队列、交换器和绑定提供命名空间和安全属性,Binding元数据为路由规则,Exchange元数据为名称、类型和属性,Queue元数据名称和它们的属性,不包括内部的消息数据。

    内存节点:只使用内存存储队列和元数据信息的节点;

    磁盘节点:不仅将队列和元数据信息存储在内存中,还会持久化到磁盘上;

    RabbitMQ集群中所有节点都是对等的,元数据会复制到集群的所有节点上,RabbitMQ的集群模式分为普通集群模式和镜像集群模式两种,两种集群模式的工作原理和优缺点分别如下:

    RabbitMQ的普通集群模式中要求至少一个节点是磁盘节点。普通集群模式下,消息队列内容只会保存在某一个(磁盘)节点上,集群中的其他节点保存此队列的元数据,当集群中的节点接收到生产或者消费动作时,将动作路由到消息队列内容所在的节点上。集群中有多个磁盘节点时,每个磁盘节点的消息队列都不同,但由于消息队列只存储在一个节点上,所以当这个节点宕机时,这个队列不能再进行生产和消费了,所以普通集群没有高可用能力。对单个队列来说,消息生产和消费只会落到存储消息内容的节点上,所以存储消息的节点的吞吐量才是队列吞吐量的瓶颈,普通集群模式不能通过增加节点数提升队列的吞吐量。

 

深入理解RabbitMQ_第2张图片

镜像集群模式:

    镜像模式下,队列的元数据和消息内容分布在多个节点上,镜像队列由一个master与多个mirror构成,通常情况下,master所在的节点是队列的master。镜像集群模式下,消息的生产和消费操作,先应用于master节点,然后在集群内部传播到其他所有mirror节点。当队列的master节点宕机后,mirror中最早的节点将被提升为master,继续执行生产和消费操作,具有高可用特性。对单个队列来说,消息的生产或消费时,消息的从master到mirror传播过程中,涉及到网络IO,磁盘IO和磁盘空间的使用。一方面,太多的副本没必要,另一方面,副本数越多传播的成本越高,吞吐量反倒下降;另外,镜像节点拥有master节点的所有信息,所以增加集群规模既不能增加队列的容量。

 

深入理解RabbitMQ_第3张图片

    总结一下,镜像集群相比普通集群的优点是高可用,但两种集群模式在吞吐量和扩展性上都是存在缺陷的,一旦队列建立,队列的吞吐量和容量就不能提升了。当然了,向集群中增加节点可以增加队列总数的容量,从总量上增加集群的吞吐量和容量。RabbitMQ产生的年代比较早,支持的功能特性比较丰富,但在场景适应性上做的不好,尤其对每个队列来说,吞吐量不能扩展是个硬伤。

个人公众号:

        自己在软件这个行业10来年的工作和学习历程中犯了不少错误,也走了不少弯路,在此公众号分享自己的成长心路和工作心得,希望给后来的从业者一个参照,不要再犯我犯过的错误,不要再走我走过的弯路。在此我也会分享工作中遇到的技术问题和自己研究技术的记录与心得;在项目过程中遇到的风险和暴露于化解风险的过程和方法;在团队管理过程中的心得和体会。后续会发布一系列专题技术文章,程序员成长系列文章,项目的系列文章,行业发展分析和展望的文章,甚至会包含婚恋和育儿的心得文章,我是个不专注却热爱生活的工程师!

深入理解RabbitMQ_第4张图片

你可能感兴趣的:(深入理解RabbitMQ)