RabbitMQ基础

 

Message

消息。消息是不具名的，它由消息头消息体组成。消息体是不透明的，而消息头则由一系列可选属性组成，这些属性包括：routing-key(路由键)、priority(相对于其他消息的优先权)、delivery-mode(指出消息可能持久性存储)等。

Publisher

消息的生产者。也是一个向交换器发布消息的客户端应用程序。

Consumer

消息的消费者。表示一个从消息队列中取得消息的客户端应用程序。

Queue

消息队列，提供了FIFO的处理机制，具有缓存消息的能力。rabbitmq中，队列消息可以设置为持久化，临时或者自动删除。

1. 设置为持久化的队列，queue中的消息会在server本地硬盘存储一份，防止系统crash，数据丢失
2. 设置为临时队列，queue中的数据在系统重启之后就会丢失
3. 设置为自动删除的队列，当不存在用户连接到server，队列中的数据会被自动删除

Exchange

Exchange类似于数据通信网络中的交换机，提供消息路由策略。rabbitmq中，producer不是通过信道直接将消息发送给queue，而是先发送给Exchange。一个Exchange可以和多个Queue进行绑定，producer在传递消息的时候，会传递一个ROUTING_KEY，Exchange会根据这个ROUTING_KEY按照特定的路由算法，将消息路由给指定的queue。和Queue一样，Exchange也可设置为持久化，临时或者自动删除。

Exchange有4种类型：direct(默认)，fanout, topic, 和headers，不同类型的Exchange转发消息的策略有所区别：

Direct(发布与订阅 完全匹配)
直接交换器，工作方式类似于单播，Exchange会将消息发送完全匹配ROUTING_KEY的Queue https://blog.youkuaiyun.com/fxq8866/article/details/62049393

Fanout（不处理路由键）
广播式交换器，不管消息的ROUTING_KEY设置为什么，Exchange都会将消息转发给所有绑定的Queue。

topic(主题，规则匹配)
主题交换器，工作方式类似于组播，Exchange会将消息转发和ROUTING_KEY匹配模式相同的所有队列，比如，ROUTING_KEY为user.stock的Message会转发给绑定匹配模式为 * .stock,user.stock， * . * 和#.user.stock.#的队列。（ * 表是匹配一个任意词组，#表示匹配0个或多个词组）

headers
消息体的header匹配（ignore）

Binding

绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。

Routing-key

路由键。RabbitMQ 决定消息该投递到哪个队列的规则。
队列通过路由键绑定到交换器。
消息发送到 MQ 服务器时，消息将拥有一个路由键，即便是空的，RabbitMQ 也会将其
和绑定使用的路由键进行匹配。
如果相匹配，消息将会投递到该队列。
如果不匹配，消息将会进入黑洞。

Connection

链接。指 rabbit 服务器和服务建立的 TCP 链接。

Channel

信道。

1，Channel 中文叫做信道，是 TCP 里面的虚拟链接。例如：电缆相当于 TCP，信道是

一个独立光纤束，一条 TCP 连接上创建多条信道是没有问题的。

2，TCP 一旦打开，就会创建 AMQP 信道。

3，无论是发布消息、接收消息、订阅队列，这些动作都是通过信道完成的。

 

virtual host

在rabbitmq server上可以创建多个虚拟的message broker，又叫做virtual hosts (vhosts)。每一个vhost本质上是一个mini-rabbitmq server，分别管理各自的exchange，和bindings。vhost相当于物理的server，可以为不同app提供边界隔离，使得应用安全的运行在不同的vhost实例上，相互之间不会干扰。producer和consumer连接rabbit server需要指定一个vhost。

https://blog.youkuaiyun.com/u013256816/article/details/55515234

1. 默认情况下发布操作是不会返回任何信息给生产者的，RabbitMQ为我们提供了两种确认方式：

1）通过AMQP事务机制实现，这也是AMQP协议层面提供的解决方案；

2）通过将channel设置成confirm模式来实现；

使用事务机制的话会降低RabbitMQ的性能（只有消息成功被broker接受，事务提交才能成功），但是采用事务机制实现会降低RabbitMQ的消息吞吐量，那么有没有更加高效的解决方式呢？答案是采用Confirm模式。

Borker

表示消息队列服务器实体。

交换器和队列的关系

交换器是通过路由键和队列绑定在一起的，如果消息拥有的路由键跟队列和交换器的

路由键匹配，那么消息就会被路由到该绑定的队列中。

也就是说，消息到队列的过程中，消息首先会经过交换器，接下来交换器在通过路由

键匹配分发消息到具体的队列中。

路由键可以理解为匹配的规则。

RabbitMQ 为什么需要信道？为什么不是 TCP 直接通信？

1. TCP 的创建和销毁开销特别大。创建需要 3 次握手，销毁需要 4 次分手。

2. 如果不用信道，那应用程序就会以 TCP 链接 Rabbit，高峰时每秒成千上万条链接

会造成资源巨大的浪费，而且操作系统每秒处理 TCP 链接数也是有限制的，必定造成性能

瓶颈。

3. 信道的原理是一条线程一条通道，多条线程多条通道同用一条 TCP 链接。一条 TCP

链接可以容纳无限的信道，即使每秒成千上万的请求也不会成为性能的瓶颈。

 

producer端confirm模式的实现原理：

 

消息什么时候需要持久化？ https://www.tuicool.com/articles/6nIBBjN

根据 官方博文 的介绍，RabbitMQ在两种情况下会将消息写入磁盘：

1. 消息本身在publish的时候就要求消息写入磁盘；
2. 内存紧张，需要将部分内存中的消息转移到磁盘；

消息什么时候会刷到磁盘？

1. 写入文件前会有一个Buffer，大小为1M（1048576），数据在写入文件时，首先会写入到这个Buffer，如果Buffer已满，则会将Buffer写入到文件（未必刷到磁盘）；
2. 有个固定的刷盘时间：25ms，也就是不管Buffer满不满，每隔25ms，Buffer里的数据及未刷新到磁盘的文件内容必定会刷到磁盘；
3. 每次消息写入后，如果没有后续写入请求，则会直接将已写入的消息刷到磁盘：使用Erlang的receive x after 0来实现，只要进程的信箱里没有消息，则产生一个timeout消息，而timeout会触发刷盘操作。

文件何时删除？

当所有文件中的垃圾消息（已经被删除的消息）比例大于阈值（GARBAGE_FRACTION = 0.5）时，会触发文件合并操作（至少有三个文件存在的情况下），以提高磁盘利用率。

publish消息时写入内容，ack消息时删除内容（更新该文件的有用数据大小），当一个文件的有用数据等于0时，删除该文件。

1.RabbitMQ集群模式

    2.普通模式(默认)

对于普通模式，集群中各节点有相同的队列结构，但消息只会存在于集群中的一个节点。对于消费者来说，若消息进入A节点的Queue中，当从B节点拉取时，RabbitMQ会将消息从A中取出，并经过B发送给消费者。

应用场景：该模式各适合于消息无需持久化的场合，如日志队列。当队列非持久化，且创建该队列的节点宕机，客户端才可以重连集群其他节点，并重新创建队列。若为持久化，只能等故障节点恢复。

    3.镜像模式

镜像队列可以同步queue和message，当主queue挂掉，从queue中会有一个变为主queue来接替工作。

镜像队列是基于普通的集群模式的,所以你还是得先配置普通集群,然后才能设置镜像队列。

镜像队列设置后，会分一个主节点和多个从节点，即1个master、n个slaver，生产者、消费者的请求都会转至master。如果主节点宕机，从节点会有一个选为主节点，原先的主节点起来后会变为从节点。

queue和message虽然会存在所有镜像队列中，但客户端读取时不论物理面连接的主节点还是从节点，都是从主节点读取数据，然后主节点再将queue和message的状态同步给从节点，因此多个客户端连接不同的镜像队列不会产生同一message被多次接受的情况。

应用场景：可靠性要求较高场合，如下单、库存队列。

缺点：若镜像队列过多，且消息体量大，集群内部网络带宽将会被此种同步通讯所消耗。

 PS：（1）镜像集群也是基于普通集群，即只有先搭建普通集群，然后才能设置镜像队列。（2）若消费过程中，master挂掉，则选举新master，若未来得及确认，则可能会重复消费。