rabbitmq使用笔记

1、RabbitMQ的几个关键概念

一、Connection和Channel

生产者/消费者都须要和RabbitMQ Broker创建链接，每一个链接都是一条TCP链接，也就是Connection。

一旦TCP链接创建起来后，客户端就建立一个AMQP信道（Channel），每一个信道都会被指派一个惟一的ID。Channel是创建在Connection之上的虚拟链接，RabbitMQ处理的每条AMQP指令都是经过信道完成的。

咱们彻底可使用 Connection 就能完成客户端和rabbitmq的通信，为何还要引入信道呢？

由于，在一般的应用场景下，可能会有多个线程（生产者/消费者）须要同时和RabbitMQ通讯，那么必然会建立多个Connection，也就是多个TCP链接。但创建和销毁TCP链接都会有很大的系统开销。

因此，RabbitMQ 采用相似NIO（Non-blocking I/O）的方法，选择TCP链接复用。在connection上创建channel，不只能够减小性能开销，同时也便于管理。

 

 

每一个线程把持一个信道，因此信道复用了 Connection 的 TCP 链接。同时 RabbitMQ 能够确保每一个线程的私密性，就像拥有独立的链接同样。当每一个信道的流量不是很大时，复用单一的 Connection 能够在产生性能瓶颈的状况下有效地节省 TCP 链接资源。可是信道自己的流量很大时，多个信道继续复用一个 Connection 的话就会产生性能瓶颈。此时，就须要开辟多个 Connection，将这些信道平均分配到这些 Connection 中，至于这些相关的调优策略须要根据业务自身的实际状况进行调节。

信道在 AMQP 中是一个很重要的概念，大多数操做都是在信道这个层面展开的。

好比 channel.exchangeDeclare、channel.queueDeclare、channel.basicPublish、channel.basicConsume 等方法。

RabbitMQ 相关的 API 与 AMQP 紧密相连，好比 channel.basicPublish 对应 AMQP 的 Basic.Publish 命令。

二、Exchange、Queue、Route

Broker：就是消息队列服务器实体，指rabbitmq实例。
Channel：消息通道，在客户端的每一个链接connection上，可创建多个channel，每一个channel表明一个会话任务。
Exchange：消息交换机，它指定消息按什么规则路由到哪一个队列。
Queue：消息队列载体，存放消息的地方，每一个消息都会被投入到一个或多个队列中。
Binding：绑定，它的做用就是把exchange和queue按照路由规则绑定起来。
Routing Key：路由关键字，exchange根据这个关键字进行消息投递。
vhost：虚拟主机，一个broker里能够开设多个vhost，用做不一样用户的权限分离。
Producer：消息生产者，生产投递消息的程序。
Consumer：消息消费者，接受处理消息的程序。

2、使用Tracing日志记录消息

RabbitMQ 的 Tracing能跟踪RabbitMQ中消息的流入流出状况。rabbitmq_tracing插件会对流入流出的消息作封装，而后将封装后的消息日志存入相应的trace文件之中。

可使用 rabbitmq-plugins enable rabbitmq_tracing 命令来启动rabbitmq_tracing插件。若是是使用docker部署的，先进入docker环境，再开启。

在rabbitmq 的GUI 管理界面 “Admin” 选项右侧本来只有 ”Users”、”Virtual Hosts”和 ”Policies“ 三项，在添加rabbitmq_tracing 插件以后，会多出”Tracing”选项。

　

Name：自定义日志名称，建议标准点容易区分。

Format：表示输出的消息日志格式，有Text和JSON两种，Text格式的日志方便人类阅读，JSON的方便程序解析。Text相比JSON格式占用空间稍大点。

JSON格式的payload（消息体）默认会采用Base64进行编码。

Max payload bytes：表示每条消息的最大限制，单位为B。好比设置了了此值为10，那么当有超过10B的消息通过Rabbit MQ时会被截断。如消息“trace test payload.”会被截断成“trace test”。

Pattern：用来设置匹配模式，如“#” 匹配全部消息流入流出的状况，即当有客户端生产消息或消费消息的时候，都会把相应的消息日志记录下来。“publish.#” 匹配全部消息流入的状况；“deliver.#” 匹配全部消息流出的状况；“publish.exchange.b2b.gms.ass”只匹配发送者(Exchanges)为exchange.b2b.gms.ass的全部消息流入的状况。

3、持久化

RabbitMQ默认是不持久Exchange、Queue、Binding以及队列中消息的，这意味着一旦MQ服务器重启，全部已声明的队列，Exchange，Binding以及队列中的消息都会丢失。为了防止丢失，须要实现持久化。但持久化会对RabbitMQ的性能形成很大的影响，可能会降低10倍不止。因此，为了提升rabbitmq的性能，没有必要持久化的能够不用设置为持久化。

一、Exchange 和 Queue 持久化

把Exchange 和 Queue 的durable 属性置为true，能够实现Queue 和Exchange 的持久化。但这里须要注意的是，只有Exchange 和Queues 的durable都为true 时才能绑定，不然在绑定时，RabbitMQ会报错的。也就是说，

二、Message 持久化

消息的持久化须要在消息投递的时候设置delivery mode值为2。消息持久化必须同时要求exchange和queue也是持久化的。
持久化的代价就是性能损失,磁盘IO远远慢于RAM(使用SSD会显著提升消息持久化的性能) , 持久化会大大下降RabbitMQ每秒可处理的消息.二者的性能差距可能在10倍以上。

- exchange持久化，在声明时指定durable => 1 - queue持久化，在声明时指定durable => 1 - 消息持久化，在投递时指定delivery_mode => 2（1是非持久化）