认识一下 RabbitMQ

分布式系统中，如何在各个应用之间高效的进行通讯，是系统设计中的一个关键。

使用 消息代理（message broker） 是一个优雅的解决方案。

RabbitMQ 就是一个被普遍应用的消息代理，遵循 AMQP协议。

接下来咱们就了解一下：

• Message Broker 概念
• AMQP 协议的核心构成
• 消息转发的 4 种模式

1. Message Broker

broker 是经纪人的意思，促成卖方、买方的交易，例如房产经纪人。

消息模型中，有消息的生产者、消费者，就至关于卖方、买方。

因此，也须要一个消息经纪人，这就引出了 message broker 的概念。

message broker 从生产者接收消息，再发送给消费者，这样，生产者、消费者能够彻底隔离。

RabbitMQ 就是一个 message broker。

2. AMQP

具体如何传递消息？要看使用的消息协议。

RabbitMQ 支持多种协议，其中最重要的是 AMQP（Advanced Message Queuing Protocol）。

AMQP 的概念模型很简单，包含3个部分：

• Queue
• Binding
• Exchange

当一个消息发布到 RabbitMQ 后，首先到达 Exchange，而后 Exchange 把消息分配给 Queue，消费者从 Queue 中获得消息。

AMQP 是一个可编程的协议，咱们能够自由配置 exchange, binding, queue。

2.1 Queue 队列

Queue 是先进先出数据结构。

Queue 是 RabbitMQ 存储消息的地方。

Queue 能够灵活的配置，例如：

• 设置 name
• 配置可靠模式，即便 broker 宕机也能够保障数据安全
• 消息自动删除
• 独占模式
• ……

2.3 Consumer 消费者

一个 queue 能够同时链接多个 consumer。

consumer 既能够本身从 queue 拉取消息，也能够由 queue 主动把消息推给 consumer。

2.4 Binding 绑定

Binding 是 Queue 与 Exchange 创建链接的规则。

每一个 Queue 都会与一个默认 Exchange 链接，咱们能够为这个 Queue 链接更多的 Exchange。

Exchange 经过 Binding 规则，把消息路由到相应的 Queue。

2.5 Exchange

Exchange 是 RabbitMQ 的消息网关。

Exchange 就像是一个接线员，收到消息后决定如何转发。

主要有 4 种转发类型：

• Direct
• Fanout
• Topic
• Header

下面具体了解一下。

3. 消息转发模式

3.1 Direct 直传

Routing key == Binding key

• routing key 是消息的一个属性。
• binding key 是绑定 queue 与 exchange 时指定的。

生产者（绿色球）发送了一个消息，带着一个 routing key -- img.resize。

当消息到达 exchange（桔色球）后，exchange 会查找全部带着 img.resize 这个 Binding key 的 queue。

找到匹配的 queue 以后，消息就会被发送给这些 queue。

若是没找到，消息会被退回给生产者，或者丢弃。

消息到达指定的 queue 以后，会以轮询的形式分派给消费者（resizer.1/resizer.2），确保负载均衡。

3.2 Fanout 扇形

此方式会忽略 routing key，把消息分派给全部链接的 queue。

最多见的场景就是消息广播。

注意，此方式是 exchange 广播给 queue，不是 queue 广播给 consumer。queue 到 consumer 仍是轮询的方式。

3.3 Topic 主题

routing key 与 binding key 进行模式匹配。

Routing key == Pattern in binding key

RabbitMQ 使用 * 和 # 这2个通配符。

* - 匹配一个词。

# - 匹配 0 个或多个词。

routing key 为 logs.error 的消息，匹配 binding key -- logs.error 和 logs.*，因此消息会进入 "only error" 和 "alllogs"。

routing key 为 logs.success 的消息，匹配binding key -- #success 和 logs.*，因此消息会进入 "only success" 和 "alllogs"。

这种形式有很是多的应用场景，能够用于发布-订阅模式、将相关数据分发给指望的 worker 等等。

3.4 Header

一种特殊类型的 exchange，基于消息头中的 key 进行路由。

使用这种方式后，就会忽略消息的 routing key 属性。

对一个 header exchange 建立 binding 时，能够对一个 queue 绑定多个 header，这种状况下，消息生产者须要告诉 RabbitMQ 匹配哪些 key，producer 能够指定一个标识 x-match，值能够是：

• any - 只有一个值应该匹配。
• all - 全部值都必须匹配。

4. 消息确认

消息到达目的地以后，broker 应该从队列中将其删除，这是为了防止消息过多致使溢出。

删除消息以前，broker 必须获得确认通知。

有 2 种通知方式：

• 自动通知：只要 consumer 接收到消息便可，无论是否处理完成。
• 明确显示通知：只有在 consumer 发送回来一个确认信息后才能够，这样保证 consumer 处理完成后再删除。

推荐阅读：

• 架构设计原则 - 高并发
• 架构设计 -- 服务降级
• 接口级故障处理策略
• 高并发的经常使用策略
• 分布式惟一ID的生成方案