RabbitMQ messaging middleware based on the concept introduced

A, AMQP Overview

What 1.AMQP that?

Before discussing RabbitMQ, you must first figure out a protocol: AMQP.

AMQP (Advanced Message Queuing Protocol, Advanced Message Queuing Protocol), is a network protocol designed specifically for messaging middleware, it supports meet the requirements of the client application (application) and messaging middleware Agent (messaging middleware broker) carried out between communication. Use only as ActiveMQ java platform based on the message middleware implemented JMS specification. And as long as message-based middleware AQMP protocol implementation, with natural cross-platform capabilities, limitations not be affected by the development of language , such as RabbitMQ supports Java, Python, C # and many other development languages.

What 2.RabbitMQ that?

RabbitMQ realized AQMP, is a language developed by Erlang messaging middleware can be deployed in a distributed and joint configurations to meet the large-scale, high-availability requirements.

3. The Message Agent and the role they play

Message broker (message brokers) to receive messages from the publisher (publishers), also known as the producer (producers) there, and in accordance with established routing rules to send the received message to consumers process messages (consumers).

Since AMQP is a network protocol, so the process of release, consumers, message broker can exist on different devices.

4.AMQP 0-9-1 model profile

AMQP 0-9-1 working process as shown below:

Message (message) is the publisher (publisher) is sent to the switch (exchange), the switch is often likened to the post office or mailbox.
Then switch the received message according to the routing rules binding distributed queue (queue).
Finally AMQP agent sends a message delivered to consumers subscribed to this queue, or consumers to obtain their own on demand.

Publishers can assign various attributes to the message when the message news release. Some attributes may be used by the message broker, but other properties are completely opaque, they can only be used by application to receive the message.

From a security point of view, the network is unreliable, the application receives the message may also fail when processing a message. For this reason, AMQP module contains the concept of a message acknowledgment: When a message is delivered from the queue to the consumer, the consumer will be informed about news agency, this can be automated, it can also be processed by the application developer message carried out. When the "message acknowledgment" is enabled, the Message Agent does not completely delete the message from the queue until it receives a confirmation receipt from consumers.

In some cases, such as when a message can not be successfully routed, the message may be returned to the publisher and discarded. Alternatively, if the message the agent delays the operation performed, the message will be placed in a so-called dead letter queue. In this case, the message publisher can choose certain parameters to handle these special cases.

Queue, switch and binding entity referred to as AMQP (AMQP entities).

Second, the switch (Exchange) type, and the switch

Switch AMQP entity is used to send messages. After the switch routes it to get a message to a queue or zero. It uses the routing algorithm is referred to binding rules (Bindings) by the switch type and the decision. AMQP 0-9-1 proxy provides four switches:

Name (switch types)	Default pre-declared names (the default name predeclared)
Direct exchange (direction switch)	(Empty string) and amq.direct
Fanout exchange (fan-shaped switch)	amq.fanout
Topic exchange (theme switch)	amq.topic
Headers exchange (head switch)	amq.match (and amq.headers in RabbitMQ)

In addition to the switch type, in a statement accompanying the switch can have many other properties, of which the most important ones are:

Name
Durability Rev (after the restart message broker, whether there switch)
Auto-delete (after all queue messages that are bound to have completed the use of this switch, delete it)
Arguments (dependent agent itself)

** switch can have two states: lasting (durable), the temporary (transient). ** persistence of the switch will still exist after the message broker (broker) restart, but the temporary switch will not (they need to be declared after the agent on the line again). However, not all scenarios require persistent switch.

1. Switch default (default exchange)

The default switch is actually a good statement by the news agency in advance, no name (the name is an empty string) is directly connected switches (direct exchange). It has a special property makes it particularly useful for simple applications: that is, each new queue (Queue) bound to automatically switch the default binding key routing (routing key) with the same name as the name of the queue.

For chestnut: When you declare a queue called "search-indexing-online" is, AMQP agent automatically binds it to the default switch, binding (binding) routing is key name is "search-indexing- online ". Thus, when carrying routing key named "search-indexing-online" to the default message is sent to the switch, the switch message may be routed to a default queue named "search-indexing-online" in. In other words, it seems, it is possible to switch the default message delivery directly to the queue, although not technically related operations do.

2. The direction switch (Direct exchange)

The switches are directly coupled to the message carries routing keys (routing key) corresponding to the message delivered to the queue. ** direct Unicast Routing Switch for processing messages (unicast routing) (although it can also handle multicast routing). ** below describes how it works:

A queue which binds to a switch, a route while imparting the binding key (routing key)
When a bond is carrying route Rwhen the message is sent directly connected to the switch, which routes it will bind to the same value for the Rqueue.

Direction switch is often used to distribute tasks to a plurality of loop worker (workers). When doing so, we need to understand that in the AMQP 0-9-1, the message is load balancing between takes place between consumers (consumer) rather than queue.

Direct switch Legend:

Direct exchange routing

3. The fan switch (Fanout exchange)

** fan switch (funout exchange) routing the message queue to bind to all of its body, without regard to the routing key bindings. ** If N queues bound to a switch on the fan, when a message is sent to that fan switch, the switch will copy the message which are transmitted to all N queues. Fan for processing a broadcast switch for routing messages (broadcast routing).

Because the fan switches deliver a copy of the message to all queues bound to it, so his application cases are very similar:

Massive multiplayer online (MMO) game can use it to deal with the global leaderboard updates and other events
Sports news sites can use to near real-time score updates to mobile client
Distribution system use it to broadcast various status and configuration updates
When a group chat, which is used to distribute messages to the user to participate in group chat. (AMQP no built-in concept of presence, XMPP and therefore may be a better choice)

Sector switch Legend:

Fanout exchange routing

4. Switch Theme (Topic exchange)

** switch topic (topic exchanges) by the message routing and queuing to key match between the binding mode switch, routing the message to one or more queues. ** topic switches are often used to implement a variety of distribution / subscription model and its variants. Theme switches are typically used to implement multicast routing messages (multicast routing).

Theme Switch Legend:

topic-exchange

主题交换机拥有非常广泛的用户案例。无论何时，当一个问题涉及到那些想要有针对性的选择需要接收消息的多消费者/多应用（multiple consumers/applications）的时候，主题交换机都可以被列入考虑范围。

使用案例：

分发有关于特定地理位置的数据，例如销售点
由多个工作者（workers）完成的后台任务，每个工作者负责处理某些特定的任务
股票价格更新（以及其他类型的金融数据更新）
涉及到分类或者标签的新闻更新（例如，针对特定的运动项目或者队伍）
云端的不同种类服务的协调
分布式架构/基于系统的软件封装，其中每个构建者仅能处理一个特定的架构或者系统。

5.头交换机（headers exchange）

有时消息的路由操作会涉及到多个属性，此时使用消息头就比用路由键更容易表达，头交换机就是为此而生的。**头交换机使用多个消息属性来代替路由键建立路由规则。**通过判断消息头的值能否与指定的绑定相匹配来确立路由规则。

我们可以绑定一个队列到头交换机上，并给他们之间的绑定使用多个用于匹配的头（header）。消息代理需要考虑某条消息（message）是需要部分匹配还是全部匹配，所以应用开发者需要定义"x-match"参数，和消息一起发给消息代理。当"x-match"设置为“any”时，消息头的任意一个值被匹配就可以满足条件，而当"x-match"设置为“all”的时候，就需要消息头的所有值都匹配成功。

头交换机可以视为直连交换机的另一种表现形式。头交换机能够像直连交换机一样工作，不同之处在于头交换机的路由规则是建立在头属性值之上，而不是路由键。路由键必须是一个字符串，而头属性值则没有这个约束，它们甚至可以是整数或者哈希值（字典）等。

三、队列（queue）

AMQP中的队列跟其他消息队列或任务队列中的队列是很相似的：它们存储着即将被应用消费掉的消息。队列跟交换机共享某些属性，但是队列也有一些另外的属性。

Name
Durable（消息代理重启后，队列依旧存在）
Exclusive（只被一个连接（connection）使用，而且当连接关闭后队列即被删除）
Auto-delete（当最后一个消费者退订后即被删除）
Arguments（一些消息代理用他来完成类似与TTL的某些额外功能）

队列在声明（declare）后才能被使用。

如果一个队列尚不存在，声明一个队列会创建它。
如果声明的队列已经存在，并且属性完全相同，那么此次声明不会对原有队列产生任何影响。
如果声明中的属性与已存在队列的属性有差异，那么一个错误代码为406的通道级异常就会被抛出。

1.队列名称

队列的名字可以由应用（application）来取，也可以让消息代理（broker）直接生成一个。队列的名字可以是最多255字节的一个utf-8字符串。若希望AMQP消息代理生成队列名，需要给队列的name参数赋值一个空字符串：在同一个通道（channel）的后续的方法（method）中，我们可以使用空字符串来表示之前生成的队列名称。之所以之后的方法可以获取正确的队列名是因为通道可以默默地记住消息代理最后一次生成的队列名称。

以"amq."开始的队列名称被预留做消息代理内部使用。 如果试图在队列声明时打破这一规则的话，一个通道级的403 (ACCESS_REFUSED)错误会被抛出。

2.队列持久化

持久化队列（Durable queues）会被存储在磁盘上，当消息代理（broker）重启的时候，它依旧存在。 没有被持久化的队列称作暂存队列（Transient queues）。并不是所有的场景和案例都需要将队列持久化。

持久化的队列并不会使得路由到它的消息也具有持久性。 倘若消息代理挂掉了，重新启动，那么在重启的过程中持久化队列会被重新声明，无论怎样，只有经过持久化的消息才能被重新恢复。

四、绑定（Binding）

绑定是交换机（exchange）将消息（message）路由给队列（queue）所需遵循的规则。如果要指示交换机“E”将消息路由给队列“Q”，那么“Q”就需要与“E”进行绑定。绑定操作需要定义一个可选的路由键（routing key）属性给某些类型的交换机。路由键的意义在于从发送给交换机的众多消息中选择出某些消息，将其路由给绑定的队列。

打个比方：

队列（queue）是我们想要去的位于纽约的目的地
交换机（exchange）是JFK机场
绑定（binding）就是JFK机场到目的地的路线。能够到达目的地的路线可以是一条或者多条

拥有了交换机这个中间层，很多由发布者直接到队列难以实现的路由方案能够得以实现，并且避免了应用开发者的许多重复劳动。

如果AMQP的消息无法路由到队列（例如，发送到的交换机没有绑定队列），消息会被就地销毁或者返还给发布者。如何处理取决于发布者设置的消息属性。

五、消费者（Consumer）

消息如果只是存储在队列里是没有任何用处的。被应用消费掉，消息的价值才能够体现。在AMQP 0-9-1 模型中，有两种途径可以达到此目的：

将消息投递给应用 (“push API”)
应用根据需要主动获取消息 (“pull API”)

使用push API，应用（application）需要明确表示出它在某个特定队列里所感兴趣的，想要消费的消息。如是，我们可以说应用注册了一个消费者，或者说订阅了一个队列。一个队列可以注册多个消费者，也可以注册一个独享的消费者（当独享消费者存在时，其他消费者即被排除在外）。

每个消费者（订阅者）都有一个叫做消费者标签的标识符，它可以被用来退订消息。消费者标签实际上是一个字符串。

六、消息确认

消费者应用（Consumer applications） - 用来接受和处理消息的应用 - 在处理消息的时候偶尔会失败或者有时会直接崩溃掉。而且网络原因也有可能引起各种问题。这就给我们出了个难题，AMQP代理在什么时候删除消息才是正确的？AMQP 0-9-1 规范给我们两种建议：

当消息代理（broker）将消息发送给应用后立即删除。（使用AMQP方法：basic.deliver或basic.get-ok）
待应用（application）发送一个确认回执（acknowledgement）后再删除消息。（使用AMQP方法：basic.ack）

前者被称作自动确认模式（automatic acknowledgement model），后者被称作显式确认模式（explicit acknowledgement model）。在显式模式下，由消费者应用来选择什么时候发送确认回执（acknowledgement）。应用可以在收到消息后立即发送，或将未处理的消息存储后发送，或等到消息被处理完毕后再发送确认回执（例如，成功获取一个网页内容并将其存储之后）。

如果一个消费者在尚未发送确认回执的情况下挂掉了，那AMQP代理会将消息重新投递给另一个消费者。如果当时没有可用的消费者了，消息代理会死等下一个注册到此队列的消费者，然后再次尝试投递。

1.拒绝消息

当一个消费者接收到某条消息后，处理过程有可能成功，有可能失败。应用可以向消息代理表明，本条消息由于“拒绝消息（Rejecting Messages）”的原因处理失败了（或者未能在此时完成）。当拒绝某条消息时，应用可以告诉消息代理如何处理这条消息——销毁它或者重新放入队列。当此队列只有一个消费者时，请确认不要由于拒绝消息并且选择了重新放入队列的行为而引起消息在同一个消费者身上无限循环的情况发生。

2.预取消息

在多个消费者共享一个队列的案例中，明确指定在收到下一个确认回执前，每个消费者一次可以接受多少条消息是非常有用的。**这可以在试图批量发布消息的时候起到简单的负载均衡和提高消息吞吐量的作用。**For example, if a producing application sends messages every minute because of the nature of the work it is doing.（？？？例如，如果生产应用每分钟才发送一条消息，这说明处理工作尚在运行。）

注意，RabbitMQ只支持通道级的预取计数，而不是连接级的或者基于大小的预取。

3.消息属性

AMQP模型中的消息（Message）对象是带有属性（Attributes）的。有些属性及其常见，以至于AMQP 0-9-1 明确的定义了它们，并且应用开发者们无需费心思思考这些属性名字所代表的具体含义。例如：

Content type（内容类型）
Content encoding（内容编码）
Routing key（路由键）
Delivery mode (persistent or not) 投递模式（持久化或非持久化）
Message priority（消息优先权）
Message publishing timestamp（消息发布的时间戳）
Expiration period（消息有效期）
Publisher application id（发布应用的ID）

有些属性是被AMQP代理所使用的，但是大多数是开放给接收它们的应用解释器用的。有些属性是可选的也被称作消息头（headers）。他们跟HTTP协议的X-Headers很相似。消息属性需要在消息被发布的时候定义。

4.消息主体（有效载荷）

AMQP的消息除属性外，也含有一个有效载荷 - Payload（消息实际携带的数据），它被AMQP代理当作不透明的字节数组来对待。**消息代理不会检查或者修改有效载荷，消息可以只包含属性而不携带有效载荷。**它通常会使用类似JSON这种序列化的格式数据，为了节省，协议缓冲器和MessagePack将结构化数据序列化，以便以消息的有效载荷的形式发布。AMQP及其同行者们通常使用"content-type" 和 “content-encoding” 这两个字段来与消息沟通进行有效载荷的辨识工作，但这仅仅是基于约定而已。

消息能够以持久化的方式发布，AMQP代理会将此消息存储在磁盘上。如果服务器重启，系统会确认收到的持久化消息未丢失。**简单地将消息发送给一个持久化的交换机或者路由给一个持久化的队列，并不会使得此消息具有持久化性质：它完全取决与消息本身的持久模式（persistence mode）。**将消息以持久化方式发布时，会对性能造成一定的影响（就像数据库操作一样，健壮性的存在必定造成一些性能牺牲）。

七、其他

1.连接

AMQP连接通常是长连接。**AMQP是一个使用TCP提供可靠投递的应用层协议。**AMQP使用认证机制并且提供TLS（SSL）保护。当一个应用不再需要连接到AMQP代理的时候，需要优雅的释放掉AMQP连接，而不是直接将TCP连接关闭。

2.通道

Some applications require multiple connections with the AMQP broker. In any case, open multiple TCP connections are not appropriate, because it would consume too many system resources and makes it more difficult to configure the firewall. Providing AMQP 0-9-1 channel (channels) for multi-connection process, the channel can be understood as a plurality of weight share a TCP connection.

In applications involving multiple threads / processes, open for each thread / process a channel (channel) is very common, and these channels can not be shared thread / process.

Communication on a particular channel and communication on other channels are completely isolated, so each AMQP methods need to carry a channel number, so that the client can specify this method which is prepared for the channel.

3. Web Hosting

In order to achieve a plurality of isolated environment (users, groups, switches, queues, etc.) on a single agent, the AMQP provides a virtual server (virtual hosts - vhosts) concept. This concept is very similar to web hosting with Web servers, which provides a completely isolated environment for AMQP entity. When the connection is established, AMQP client to specify which virtual host.