rabbitmq 简单梳理

时间:2023-12-26 22:38:43

概念:

生产者(Producer,简写P),负责发布消息。

“交换机”(Exchange, 简写X), 负责中转消息。

路由(Route, 简写R), 即 X->Q的路线名。

消息队列 (Queue, 简写Q), 负责临时存储消息。

消费者(Customer,简写C), 负责处理消息。

完整关系图解:

rabbitmq 简单梳理

P: 负责发布消息, 可绑定到一个exchange上,默认的exchange名为空字符串,类型为direct。 推送消息时,需要指定路由名(routing_key)。
  发布消息时,需要指定:

      routing_key, 路由名

      body,消息正文

      properties,消息属性

        AMQP协议定义的消息属性支持14种之多,最常用的有四种:

          delivery_mode: 2---持久化消息。  其他值----临时消息(不存文件/数据库)

          content_type: 内容类型(json类型设为: application/json)

          reply_to: 回调队列名称,

          correlation_id: 消息id, 可用于匹配响应内容。

X: 负责路由消息,类型有

  • direct, 直接转发, P在推消息时,指定routing_key(路由关键字), 此类型的X直接找:1. 路由名与其匹配的路由, 2.名字与其匹配的队列(Q),没找到则放弃。
  • fanout,广播消息, 此时无论P怎么指定routing_key,将无条件转发给绑定到exchange上的所有队列(Q)。
  • topic, 可认为是direct改进版(模糊匹配版); 示例图如下:

      rabbitmq 简单梳理

      topic类型的路由, 其名为"关键词1.关键次2.关键词n",每个关键词均可用通配符取代 (* / #)

      * :  代表一个单词(关键字)

      # : 代表0~n个单词(用.分隔)

      对于上图的路由情况:

        eg.

          消息A.orange.B 匹配*.orange.* , 去Q1

消息A.B.rabbit, 匹配*.*.rabbit, 去Q2

消息lazy.B.orange, 匹配  *.orange.* 和  laze.# 去 Q1和Q2, 消息被处理两次!

消息lazy.B.rabbit, 匹配 *.*.rabbit 和 lazy.# 去Q2, 由于是统一个队列,只投递一次。只处理一次!

          消息hardworking.A.cow, 不匹配任何路由规则,消息将被丢弃!

      路由的声明: 在绑定队列到Exchange上时声明。

  • headers, 暂无资料。

路由:队列绑定到exchange上,需要指定路由,默认为''(路由名为空时,匹配队列名)

Q: 队列, 缓存消息,

可进行持久化(durable), 在少数极端条件下,即使durable的队列消息也可能丢失。

  要持久化消息,处理队列要声明为可持久化的,消息在推送时,也需要指定其属性为可持久化的(delivery_mode = 2)。

有临时队列(C指定,用exclusive属性声明队列), 随消费者销毁而销毁(专用)。

   队列在分发消息给消费者(多个消费者)时,默认是按消息条数平分的。即:若队列(Q)里有10条消息, 有两个消费者(C1和C2), 那么C1得到(1,3,5,7,9), C2得到(2,4,6,8,10)。

   若想队列在下发消息时,考虑到消费者的处理能力,做到处理大而耗时任务的少发,处理小而快速的任务的消费者多发(即负载均衡), 需要配置消费者同时处理最大任务数属性(prefetch)

    rabbitmq 简单梳理

  pika 里面是:  channel.basic_qos(prefetch=1)

C: 消费者可以绑定到一个队列上,进行监听,消息来了即处理, 从这个角度讲, 消费者可以作为server端。

消费者在轮询监听到消息,交给回调函数(callback)来处理消息。

  消费者指定消息队列中的消息的删除模式(确认后删除/不需要确认删除),通过no_ack参数(默认为False, 即需要确认), 需要确认的消息在其回调函数中,得进行确认操作。以保证消息总能得到处理,不会丢失。默认, 如果一个消费者进程挂掉了, 没有确认"消息处理完了", 消息队列将重发此消息给下一个消费者(保证服务可靠性)。

  

应用: 

1. 提高系统并发性:

  对于某些可以异步处理的任务(发送短信/邮件/推送等等),及时将任务publish到消息队列中,及时返回,不阻塞请求。

2. 应用于某些设计模式:

  消息发布/订阅

3. rpc

  demo参考这里

转载请注明来源:http://www.cnblogs.com/Tommy-Yu/p/5802264.html

谢谢!