RabbitMQ-基本概念

RabbitMQ的基本概念

Binding-绑定

• Exchange和Exchange、Queue之间的连接关系

• Binding中可以包含Routing Key或则参数

  注意:
  default Exchange 不能进行Binding，也不需要进行绑定
  除default Exchange之外，其他任何Exchange都需要和Queue进行Binding，否则无法进行消息路由（转发）
  Binding的时候，可以设置一个或多个参数，其中参数要特别注意参数类型
  Direct Exchange、Topic Exchange进行Binding的时候，需要指定Routing key
  Fanout Exchange、Headers Exchange进行Binding的时候，不需要指定Routing key

Queue-消息队列

• 消息队列，实际存储消息数据

• Durability：是否持久化，Durable：是，Transient：否

• Auto delete：如选yes，代表当最后一个监听被移走之后，该Queue会自动删除

  注意:

• 关于Queue名称最长？
  RabbitMQ规定，队列的名字最长不超过UTF-8编码的255字节。不过一般没人无聊到声明名字那么长的队列
  吧。。。

• 关于Queue名称雷区？
  由于RabbitMQ内部的Queue命名规则采用 “amq.”形式，所以当我们声明自己的Queue时，注意不要与此规则
  冲突，否则会报异常。

• 关于队列属性？
  Durable ：代表该队列是否持久化至硬盘（若要使队列中消息不丢失，同时也需要将消息声明为持久化）；
  Exclusive :是否声明该队列是否为连接独占，若为独占，连接关闭后队列即被删除；
  Auto-delete：若没有消费者订阅该队列，队列将被删除；
  Arguments：可选map类型参数，可以指定队列长度，消息生存时间，镜相设置等

• 声明了一个已经存在的队列？
  如果队列已经存在，再次声明将不会起作用。若原始队列参数和该次声明时不同则会报异常。

• 队列中消息顺序？
  默认情况下是FIFO，即先进先出，同时也支持发送消息时指定消息的优先级。

• 队列消息存放位置？
  对于临时消息，RabbitMQ尽量将其存放在内存，当出现内存告警时，MQ会将消息持久化至硬盘。对于持久化
  消息与Lazy-queues，MQ会先将消息存入硬盘，消费时再取出。

• 队列中消息的消费？
  默认情况下，MQ会设置消费者的消费确认模式为自动。对于一些重要消息的处理，推荐确认模式改为手动。
  （nack和reject区别？nack可以一次拒绝多条消息）

• 队列中消息的消费速度？
  通过Prefetch（通道上最大未确认投递数量）设置消费者每次消费的条数，一般将该值设为1，但他会降低吞
  吐量。RabbitMQ官网建议的是100-300.（更建议反复试验得到一个表现符合期望的值）

• 队列中消息状态？
  队列中的消息共有俩种状态，一是准备投递，二是已投递但未确认。

• 队列最大长度？
  声明队列时可以指定最大长度，需要注意的是只限制状态为准备投递的数量，未确认的消息不计算在内。当队
  列长度超过限制，MQ会根据策略选择丢弃（默认）或者将消息投递进死信队列。

• 关于死信队列？
  其实更准确的说法是死信交换机，提前声明一个交换机，在声明队列时使用“x-dead-letter-exchange”参
  数（可指定routKey）将队列绑定到该死信交换机。消息有以下情况之一会成为死信：被reject或者nack，消
  息超过生存时间，队列长度超过限制。

• 关于不能路由到队列的消息？
  这个和上面一样，其实不算Queue系列而是Exchange。针对消息无法路由到队列的情况MQ提供了Alternate
  Exchange处理。声明Exchange时添加args.put(“alternate-exchange”,”my-ae”)参数。即当该交换机存
  在无法路由的消息时，它将消息发布到AE上，AE把消息路由到绑定在他上面的消息。

Message-消息

• 服务器和应用程序之间传送的数据

• 本质上就是一段数据，由Properties和Payload（Body）组成

• 发送消息可以为消息指定一些参数
  Delivery mode: 是否持久化，1 - Non-persistent，2 - Persistent
  Headers：Headers can have any name. Only long string headers can be set here.
  Properties: You can set other message properties here (delivery mode and headers are
  pulled out as the most common cases). Invalid properties will be ignored.
  Valid properties are:

  1. content_type ： 消息内容的类型
  2. content_encoding： 消息内容的编码格式
  3. priority： 消息的优先级
  4. correlation_id：关联id
  5. reply_to: 用于指定回复的队列的名称
  6. expiration： 消息的失效时间
  7. message_id： 消息id
  8. timestamp：消息的时间戳
  9. type： 类型
  10. user_id: 用户id
  11. app_id： 应用程序id
  12. cluster_id: 集群id
  13. Payload: 消息内容
      ————————————————
      版权声明：本文为CSDN博主「gmHappy」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
      原文链接：https://blog.csdn.net/ctwy291314/article/details/83183633

  注意:

  如何保证消息不丢失

  1. Exchange需要持久化
  2. Queue需要持久化
  3. Message需要持久化

Virtual host-虚拟主机

• 虚拟地址，用于进行逻辑隔离，最上层的消息路由
• 一个Virtual Host里面可以有若干个Exchange和Queue
• 同一个Virtual Host里面不能有相同名称的Exchange和Queue