RabbitMQ之AMQP0-9-1模型解释

由于 AMQP 0-9-1 是一种网络协议，所以 生产者、消费者、和消息代理 都可以运行在网络中不同的机器上。

消息被发送到交换机 exchanges ,而后交换机利用绑定规则 bindings 将消息副本发布到消息队列 queue ，然后消息队列中的消息，要么被传递给了订阅消息队列的消费者，要么消费者按照需要从消息队列拉取 fetch/pull 消息。

当一条消息发布的时候，发布者可能会指定一些消息属性 message attributes(也叫message meta-data消息元数据) ，其中有一些消息属性是用于消息中间件处理消息，其余的部分则是用于消息消费者对于消息中间件完全透明。

由于网络的不稳定性，消息在传输过程中可能出现失败的情况，鉴于此 AMQP 0-9-1 提供了一种消息确认机制 message acknowledgements : 当一条消息传递给消费者后该消费者发送一条通知 notifies 给消息中间件来确认消息，无论是自动的还是开发者自己这样做，当消息确认机制使用时，只有当消息代理收到通知后才会将该条或该组消息从消息队列中移除。

在一些特定情况下，比如当消息不能被路由时，消息可能会被返回给消息发布者，或者删除，或者如果消息代理实现了某种扩展插件，则这些无法被路由的消息可能会被放入一个称之为 dead letter queue (死亡标记队列)的队列中，发布者可以通过指定一些确定的 消息属性 message attributes 来响应出现这种情景时消息应该如何被处理。

exchange、bindings、queue 均被称为 AMQP实体-AMQP entities

）应该有具体应用来完成。

这种方式给了开发者很大的自由空间，但是也需要他们能意识到可能潜在的定义冲突，实际上定义冲突很少见，大多都由错误的设定引起。

交换机 exchanges 是 AMQP 0-9-1 协议定义的消息应该被送达的实体。交换机拿到消息并且将它路由到一个或者多个队列中去，具体的路由算法由交换机的种类决定。交换机类型和路由规则被统称为 (binding) 绑定规则（交换机和消息队列间的绑定规则）， AMQP 0-9-1 代理提供了四种交换机类型

除了交换机类型以外，交换机还定义了一些属性，其中最重要的属性如下：

• Name 名称
• Durability 持续性（控制交换机能从在重启后恢复）
• Auto-delete 交换机在最后一条消息出栈之后是否删除
• Arguments 参数，可选用于插件或者消息代理的一些特殊用途

交换机可以是持续性的也可以是瞬态的，持续性的交换机可以在重启后恢复，而瞬态的交换机则需要重新定义。

比如当你定义了一个名为 search_index_online 的消息队列时，队列会使用 search_index_online 自动绑定到默认交换机，消息发布者可以使用默认的交换机附带 search_index_online 的路由键来发送消息到消息队列，看起来没有定义任何交换机，像是直接将消息传递给了队列。

直转交换机基于路由键 routing key 给消息队列转发消息，直转交换机可用于消息单播（尽管实际上可以用于多播消息）直转交换机模式如下

• 消息队列通过路由键K与交换机绑定
• 当交换机收到一个需要转发到路由键等于R的消息队列时，如果K=R,则交换机将消息发送给消息队列

直转交换机通常用于任务分发，但在使用时必须注意，在 AMQP 0-9-1 协议中消费者之间才有负载均衡，而不是消息队列之间。直转路由过程如下

扇面交换机是一种多播交换机，会将消息路由到所有绑定到该交换机上的消息队列，并且会忽略路由键，如果有N个消息队列绑定到该交换机上，则交换机会将消息副本传递给每一个绑定到上面的消息队列，扇面交换机的应用场景

• 大量多用户在线游戏，可以将消息广播给所有人比如流行游戏吃鸡，全员广播时很切合此类业务需求。
• 体育新闻类场景，可以利用扇面交换机将最新分数以及信息广播到所有手机端

扇面交换机图示如下

消息可以指定一组或者多组头部信息用于头部交换机匹配消息队列，我们可以使用 x-match 头来指定满足任意一组还是必须所有满足才能将消息传递给消息队列 x ,可以选 any/all

需要注意的是在交换机中以 x- 开头的头部将不会参与解析。

队列用于储存消息，和其他消息系统和任务系统大致相同，队列和交换机共享一些属性，也定了一些额外的属性

• Name
• Durable 当一个代理重启之后是否会恢复
• Exclusive 独占，只维持一个链接，当链接关闭后，该队列是否会被删除
• Auto-delete 至少有一个订阅者，当最后一个订阅者取销订阅之后，是否会被删除
• Arguments 额外属性，一般用于消息代理

要使用一个队列必须声明队列，在声明队列时如果队列已经存在并且声明的队列和已存在队列的属性不一致时会抛出一个通道级别的异常 PRECONDITION_FAILED 不满足前提条件

以 amq. 开头的队列名称是消息代理内部使用的，当应用创建这类名称的队列时，会抛出 ACCESS_REFUSED 异常

在队列中保存消息是无意义，只有当消息能够被应用消费时才有意义在 AMQP 0-9-1 协议模型中消费者有两种方式获得队列中的消息

push API
pull API

在 push api 模式下，消费者必须标明对某种类型的消息有兴趣，此种情况也叫 注册一个消费者或者订阅一个主题 当然可能完全可能存在不止一个消费者订阅了某一个消息队列，每一个消费者都有一个标识符叫 consumer tag 消费标签，消费标签是一串字符串，可以用来退订消息队列。

当消费者接收和处理一个消息时有可能出现一些意外情况，比如消息无法处理，或者消费应用程序由于某些原因崩溃亦有甚者由于网络原因导致接收到的消息产生问题。这种情景下就产生了一个问题！? AMQP 代理该什么时候从队列里将这些消息删除呢? AMQP 0-9-1 规范推荐两种选择

• 在代理将消息发送给消费者之后(不管是使用 basic.deliver 还是使用 basic.get-ok 这两个 AMQP 方法)
• 在消费者返回一个确认标记后(使用 basic.ack - AMQP 方法)

前一种称之为 自动确认模型 ，后一种称为 显示确认模型 在 显示确认模型 的情况下，消费者应用可以控制何时发送确认标记，可以是在收到消息后，也可以是在消息处理完成或者被保存之后，或者对消息的处理全部完成之后。

如果一个消费者由于宕机或者崩溃没有返回确认标记，那么消息队列将重发该消息到另外的消费者应用，如果没有消费者应用程序订阅到该消息队列，那么消息队列将会等到有消费者订阅之后，再将消息重新传递给消费者。

在 AMQP 模型下消息是有属性的，有一些属性是 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

除此之外消息还有一个负载 payload(消息携带的数据) ，该负载对 AMQP 协议是不透明的，对消息来讲负载可有可无，在负载区应该存放序列化数据如 JSON、Thrift、Protocol Buffers and MessagePack 使用的文档类型和编码应该在 content-type 和 content-encoding 中指定

消息的持久化需要消息自己指定持久化模型，当消息需要持久化时，消息将会被保存到磁盘中，当消息代理重启后，这些消息将会被恢复，但是消息持久化会影响性能。