Preface

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

Application 整合模式

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

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

Filed Based Integration

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

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

Shared Database Integration

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

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

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

Direct Connection Integration

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

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

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

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

• 不限传递的资料格式

• 需要额外的 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

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

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 & 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 的内部架构图：

• 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 而已。