rabbitmq 简单梳理

概念：

生产者（Producer，简写P），负责发布消息。

“交换机”（Exchange, 简写X）， 负责中转消息。

路由（Route， 简写R）， 即 X->Q的路线名。

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

消费者（Customer，简写C）， 负责处理消息。

完整关系图解：

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改进版（模糊匹配版）； 示例图如下：

　　　　　　

　　　　　　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)

　　　　

　　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

谢谢！