您现在的位置是:主页 > 运维部署 >

RabbitMQ Message Queue 简介

2021-01-06 17:41:50运维部署 1032人已围观

Preface


由于目前 Message Queue 在系统架设设计时很常出现,到底这类型的元件有什麽特性? 可以为系统带来什麽优点? 以及其相关的特性 & 运作方式 (以 RabbitMQ 为例)。以下的部份会进行说明解释。

Application 整合模式

在一个系统中,一般不会只有一隻程式在运作,而是会有多隻程式同时负责各种不同的任务,而程式之间难免会有互相传递资料进行处理的需求,而这类的需求,以下都统称为 applcation 的整合。

而一般常见的 application 整合方式大概可以分为以下几种:

Filed Based Integration

File Based Integration

  • source application 会根据需要处理的工作,产生新的档案到特定的路径

  • 其他的 process application 则会是一直监控该路径有没有新档案,有新的档案则取出进行处理

Shared Database Integration

Shared Database Integration

  • source application 收到新任务时,或将资讯写入 DB table 中

  • processor application 则是持续监控 DB 中的特定 table,若有新纪录则取出进行处理

  • processor application 处理完工作后可能会将状态回写到 DB 中

Direct Connection Integration

Direct Connection Integration

  • source application 直接传递讯息给 processor application

  • 可能透过 TCP/IP 或是 named pipe connection 的方式传递资料

  • 不限传递的资料格式,连线两端的 application 传递的资料格式可自订,可能是纯文字、XML or JSON

透过 Message Broker 以非同步的方式传递讯息Asynchronous Messaging

Message Broker Based Integration

  • 不限传递的资料格式

  • 需要额外的 Message Queue middleware 的协助,也有可能被称为 Message Broker 或是 Message Bus

  • Message Broker 搜到讯息后(来自 producer application )会转发给 consumer application

从上面看得出来,其实透过 Message Broker 的方式是以上很多不同方式改良后所产生的结果

使用 Message Queue 有什麽优点?

了解 Message Queue(Broker) 的简单架构后,那接下来的问题可能是:到底在系统中加入 Message Queue,具体可以带来哪些好处 or 优点呢?

以下列出几项说明:(publisher 为讯息传送者,consumer 为讯息接收者)

  • 将 publisher & consumer 进行 decouple 了,因此程式开发人员可以各自专心负责规模较小 & 单纯的程式开发工作

  • publisher & consumer 不需要知道双方的实际的位置(例如:IP address),只要将资料往 message queue 送就好

  • 即使 consumer 短暂的无法提供服务也没关係,message queue 可以将资料暂存起来,等待 consumer 重新上线时再送过去

  • 比起持续 polling 的方式相对有效率的多

  • 提供了一个可靠的方式,让讯息传递 & 工作处理两件事情可以用非同步的方式进行

  • 当单一 consumer 不足以完成所有工作时,可以很容易的增加 consumer 数量进行水平扩展

从上面的优点可以看出,加入了 Message Queue,对于整体系统中各个不同元件的解耦很有帮助,同时了也带来了水平扩展的可能性。(当然这部份也会牵涉到系统流程面上的设计,并非只透过系统架构就可以完成)

使用场景范例

以下就透过两个范例说明,介绍 Message Queue 在整体系统中可以作为什麽样的角色。

Case 1

Message Queue Case 1

从上图可以看出,当 product 有任何更动时,需要后端资料库的 search index 时,相关的资讯会先传进 message queue,然后会有其他 worker(consumer) 接收进行处理。

Case 2

Message Queue Case 2

在一个电子商务网站,可能会因为以下不同的理由,以非同步的方式寄送 email 给会员:

  • 验证 E-Mail address

  • 重设密码

  • 订单确认

  • 促销活动

Messaging System 中的标准组成元素

了解 Message Queue 的功能之后,接著说明在一个 Messaging System 会包含的标准元素:

  • Message:这是最主要的部份,简单来说 message 就是要从一个 application 传递到另一个 application 的资料,可以是很多形式,例如:command、query 或是任何事件资讯;而每个 message 会包含两个部份,分别是 routing information & payload(实际资料)。

  • Producer/Publisher:producer 是产生 message 并将其传到 message broker

  • Consumer/Receiver:收取来自 message broker 的 message 并进行处理

  • Message Queue:是个存放来自 producer 的 message list,通常一个 messaging system 中会有多个 queue,而每个 queue 都会有一个识别名称

  • Message Broker:将 message 从传送者转发到 receiver 的一个中间者

  • Router/Exchange:根据软体设定,决定 message 传递的路径,将不同的讯息转发进不同的 queue 中

    Routing 的概念在 RabbitMQ 中以 Exchange 来表示

  • Connection:真实的 TCP 连接,像是 producer & message broker 之间的连接,或是 message broker 与 consumer 之间的连接

  • Channel:在真实的 TCP 连接中定义出来的 virtual connection,这才是实际上 producer/consumer 与 message broker 之间的连接改念

  • Binding:Binding 定义了 Exchange & Queue 之间的关係以及讯息 routing 的设定,可能还包含了一些 filter 的设定
    Message Queue Case 2

细部探究 Message, Queue & Exchange 的属性资讯

了解了上面关于 Messaging System 的标准组成元素之后,可以大致了解一个 Message Queue 大概是如何与外部 application 进行沟通运作的;但如果要更探究 Message Queue 内部的运作细节,可以从标准组成元素中的属性(attribute)来进行了解。

这部份的学习会以 RabbitMQ 为主,因此以下属性介绍会以 RabiitMQ 为主,但跟其他主流的 Message Queue 应该不会差异太大

Message 的属性

  • Routing Key:用来决定讯息进入到 Messaging System 后如何被转发的资讯

  • Headers:key/value 的资讯集合,可用来作为讯息 routing 之后或是传递 publisher 想要传递的额外讯息

  • Payload:实际所要传递的资料

  • Publishing TimeStamp(optional):publisher 所提供的 timestamp 资讯

  • Expiration:Message 可停留在 Queue 中的存活时间,超过 expiration 的设定则 message 会视为 dead 而不会传送

  • Delivery Mode:会有 persistent or trasient 两个选项,而 persistent 会将 message 写入 disk 中,即使 RabiitMQ 服务重启,讯息也都不会遗失,而 trasient 则不会

  • Priority:message 的优先权(0~255, 这个需要 Queue 支援才可以)

  • Message ID(optional):由 publisher 给入,用来识别 message 的 ID 资讯

  • Correlation ID(optional):在 RPC 场景中用来匹配 request & response 用的资讯

  • Replay To(optional):在 request-response 场景中会使用到的 exchange 或是 queue 的名称

Queue 的属性

  • Name:唯一的名称,最多 255 个字元的 UTF-8 字串

  • Durable:指定在 RabbitMQ 重启后保留 or 移除 Queue 的依据

  • Auto Delete:没有任何订阅者的情况下是否自动移除

  • Exclusive:只服务特定一个 connection,一旦该 connection 断掉就会移除 Queue

  • Max Length:最多可以停留在 Queue 中的 message 数量,可以指定若超过会从最旧的讯息开始移除或是拒绝新的 message 进入

  • Max Priority:priority 可设定的最大值

  • Message TTL:存入到 Queue 中的 Message 的 TTL(若是 Message & Queue 都有 TTL 的设定,会以较低的为主)

  • Dead-letter Exchange:可用来指定过期 or 被丢弃的 message 被自动传送到某一个 exchange

  • Binding Configuration:Queue & Exchange 之间的关联资讯 (每个 Queue 都必须与某个 Exchange 绑定,确保可以从 Exchange 取得 message)

Exchange 的属性

  • Name:Exchange 的名称(必须唯一)

  • Type:Exchange 的运作类型,会是 Fanout, Direct, Topic, Headers 四种之一

  • Durability:与 Queue Durability 相同,用来决定在 RabbitMQ 服务重启后会不会依然存在

  • Auto Delete:设定是否在没有任何 Queue 绑定的情况下,就自动移除

  • Internal:若设定为 Internal,表示仅能接收来自其他 exchange 的 message,无法接收来自 publisher 的 message

  • Alternate Exchange:指定无法 route 的 message 的去向

  • **Other Arguments(x-arguments)**:Exchange 其他的 metadata,可能会用于其他的 plugin 中

Exchange

要切入 RabbitMQ 之前,Exchange 的概念是必须先了解的,以下是 RabbitMQ 的内部架构图:

RabbitMQ Exchange

  • Exchange 是 RabbitMQ 系统中负责转发讯息的元件

  • Message Producer 无法将讯息直接传到 Queue 中,在 RabbitMQ 中讯息的第一个进入点是 Exchange

  • 实际储存讯息的 Queue 会根据使用者的设定,与不同的 Exchange 进行绑定

  • 当 Exchange 收到讯息后,就会转发到与其绑定的 Queue (可能 0 到多个不等)

  • Exchange 仅能将讯息转发到与其绑定的 Queue 上

  • Exchange 有四种转发模式,分别是 Fanout, Direct, Topic, Headers

  • 至少会有一个预设 Exchange 存在于 RabbitMQ 系统中,称为 default exchange,转发的模式为 direct;每个新建立的 Queue,若是没指定 exchane 资讯,就会与预设的绑定

总结

透过上面关于 Messaging System 的标准组成元素说明,可以了解到一个 Message Queue 在整体系统上所扮演的角色;加上内部组件的属性(attribute)说明,也大致可以推敲出一个 Messaging System(以 RabbitMQ 为主) 内部运作的状况。

因此在实际使用上,我们可以利用 Message Queue 有效的将 application 进行解耦,让大问题拆分为小问题,并且让 developer 可以专注在特定的系统功能上,让 application 面对的,就是 Message Queue 而已。

站点信息

  • 文章统计 10 篇文章
  • 微信公众号:扫描二维码,关注我们