RabbitMQ是一种消息队列，用于程序间的通信。形象地说，MQ就像一个邮局，发送者将消息写入MQ，MQ负责把消息发送给接收者。RabbitMQ可支持Java, PHP, Python, Go, JavaScript, Ruby等多种语言。然并卵，人生苦短，我还在用Java…
本文主要介绍RabbitMQ的基本概念和模型。
几个基本概念
图1 rabbit_model
RabbitMQ的基本模型如图1所示。先介绍一些术语。
生产者(producer)
在图中为P，表示消息的发送者。
交换机(exchanges)
在图中为X, 生产者发过来的消息需要经过交换机，交换机将决定将消息放到哪些队列当中。
队列（queue）
队列在图1中由红色矩形阵列表示，负责保存消息和发放消息。
消费者（consumer）
在图中为C，代表等待接收消息的程序。
信息流
消息是怎么从生产者传递到消费者的呢？
首先，生产者发送消息到交换机，同时发送一个key，通过这个key，交换机就知道该把消息发到哪个队列。随后交换机把消息发送到相应的队列中。由队列将消息发送给消费者。
消费者监听某些队列，当有消息过来时，就立即处理消息。
那么，接下来就有两个问题：
- 交换机是如何根据key来分配消息到队列？
- 队列怎样将消息发送给消费者？
交换机类型
这个部分将回答第一个问题。交换机如何根据key来分配消息到队列?
RabbitMQ的交换机有四种类型：direct, topic, headers, fanout
fanout
fanout 交换机就跟广播一样，对消息不作选择地发给所有绑定的队列。以图1为例，两个队列都将收到消息。
direct
图2 direct
在direct模式里，交换机和队列之间绑定了一个key，只有消息的key与绑定了的key相同时，交换机才会把消息发给该队列。如图2所示，消息的key为orange时，消息将进入队列Q1;key为black或者green时，消息将进入队列Q2。若消息的key是其他字符串，被交换机直接遗弃。
图3 多重绑定
同时，交换机支持多重绑定，多个队列可以以相同的key与交换机绑定。如图3所示，当消息的key为black时，消息将进入Q1和Q2.
topic
topic模式可以理解为主题模式，当key包涵某个主题时，即可进入该主题的队列。topic模式的key必须具有固定的格式：以”.”作为间隔的一串单词；比如：“quick.orange.rabbit”，key最多不能超过255byte。
交换机和队列的key可以以类似正则表达式的方式存在，有两种语法：
- “*”可以替代一个单词
- “#”可以替代0个或多个单词
图4 topic
说话比较抽象，看图4。图中，Q1与交换机绑定的kye为：“*.orange.*”，故当消息的key为三个单词，且中间的单词为orange时，消息将进入Q1。Q2与exchange绑定的key为”rabbit.#”，当消息的key以rabbit开头时，消息将进入Q2。
其实，图中的key描述的是动物的属性，第一个单词表示反应速度，第二个单词表示颜色，第三个单词表示名称。绑定的key定义了它们的筛选规则，所有橘色的动物都将进入Q1,所有懒洋洋的动物都将进入Q2,老鼠也将进入Q2(老鼠并不懒呀，不过人家就这么定的也没办法)。
下面给出更具体的例子帮助理解：
key –> 进入的队列
lazy.orange.elephant –> Q1和Q2
quick.orange.fox –> Q1
lazy.pink.rabbit –> Q2
quick.brown.fox –> 被直接无视
headers
官网没介绍这个模式呀，大概不常用吧，有缘再见［微笑挥手脸］。
队列分发消息的方式
这一部分将回答第二个问题。队列怎样将消息发送给消费者？
图5 Round-robin dispatching
循环发放（Round-robin dispatching）
队列分发消息给消费者的方式采用循环发放。举例来说，若队列里有四个消息w,x,y,z，则C1将得到消息z和x,C2将得到消息y和w。即每个消费者按顺序每人发一个消息。
注意，在这种分配方式下，消息其实在刚进入队列的时候就已经内定好将要被分发的消费者。即z,x一定是给C1,y,w一定是给C2。
这种方式存在一些隐患，如果z和x都是耗时的命令、y,z都是简单的命令，C1将不停地工作，而C2就比较空闲，造成资源浪费。
公平发放解决了上述问题。
公平发放（fair dispatching）
这种方式下，队列只会把消息给空闲的消费者。如果它看到某个消费者正忙，就查找下一个空闲消费者。
消息的确认（Message acknowledgment）
若没有特别设定，消息一旦被队列分发给消费者，就被rabbitmq从内存中删除。
在这种情况下，如果将一个正在处理消息的消费者强行关闭，那么，消息将未被完全处理，且RabbitMQ完全不知情。
为了解决上述问题，可以配置使得消息处理完后，向RabbitMQ返回一个acknowledgment。RabbitMQ直到收到acknowledgment后，才将消息删除。
当消费者死亡时（its channel is closed, connection is closed, or TCP connection is lost），RabbitMQ会知道这个消费者发生问题了，将重新发送消息给空闲的消费者。
消息没有timeout，即使消费者处理很长很长时间，乃至无穷无尽，RabbmitMQ也认为消费者正在处理。（真有耐心）
其实，消息的确认是默认开启的，不需要特地设置。
以上
如有错误，还请指教
更正：
- 交换机类型－topic章节中，示例有两个重复的key:
- 已更正为：
