上個觀念 IOC 強調程式碼的品質，第二個觀念 message queue 強調的則是 “訊息的溝通”。

接下來會利用三篇文章的篇幅講解 message queue 的基礎概念，第一篇文章以介紹 message queue 概念與使用時機為主，第二篇則是選擇介紹業界常用的 RabbitMQ service，第三篇則是結合第一篇的知識與第二篇的 RaabitMQ 實作一個小範例。

在進入主題 message queue 以前，想先跟各位談談應用程式的整合 - Application Intergration。

Application Intergration

在一個系統中，一般不會只有一隻程式在運作，而是會有多隻程式同時負責各種不同的任務，而程式之間難免會有互相傳遞資料進行處理的需求，而這類的需求，以下都統稱為 applcation 的整合。

而常見的 Application Intergration 方式又分為以下幾種：

• File Based Intergration
• Shared Database Intergration
• Direct Connection Intergration
• Asynchronous Message Broker

File Based Intergration

source application 根據要處理的任務，產生檔案到特定的路徑，其中任務成功或失敗可以存放到不同 folder 中。
而其他接收訊息的 application(或稱 process application) 則是不停監控該路徑有沒有新檔案產生，有則取出檔案進行處理。

Shared Database Intergration

基本上方法和 file based 差不多：

• source application 收到新任務時，將資料寫入 db 中
• process application 監聽的對象從路徑中的檔案換成 database，若有新資料則進行處理
• process application 處理後將狀態寫回 db 中

Direct Connection Intergration

• source application 直接傳訊息給 process application
• 可能透過 TCP/IP 或是 named pipe connection 的方式傳遞資料
• 傳遞資訊的資料格式並沒有限制，由連線兩端的 application 自訂，可以是純文字、XML 或 JSON。

Asynchronous Message Broker

這個方式也就是今天的主角，而它的特性有：

• 不限傳遞資料格式
• 需要額外 message queue middleware 協助，也會被稱作 message broker 或 message bus
• message broker 收到來自 source application 的訊息後，會轉發給 process application，而在這個方式中，source application 與 process application 通常又各自被稱為 producer 與 **consumer。

了解幾種不同的方式後，可以了解到 message broker 的方式是以上幾種模式改良後產生的結果。

What is message queue?

訊息佇列（Message Queue，簡稱MQ），從字面意思上看，本質是個佇列，FIFO 先入先出，只不過佇列中存放的內容是message。
其主要用途：

• 不同程序 Process 之間
• 不同執行緒 Thread 之間
• 不同服務之間 (Microservice)

的訊息溝通

queue

queue 是將等待處理的任務排好，之後依照順序將任務從 queue 中取出處理（先進先出）， Message Queue 就是將存在 queue 中的 message 在兩端（Producer、Consumer）中傳遞。

message

Message 其實就是 sender 與 reciever 之間傳遞的資料，例如通知一個服務執行某項任務的訊息或是傳遞一項 task 執行後的相關資訊

基本上 message queue 的架構由 Producers 、 Message Queue 、 Consumers 組成， Producers 負責創建訊息並傳遞訊息至 Message Queue，Consumers 負責從 queue 中取出訊息並執行對應的行為。存放在 queue 中的 Message 會在被 Consumers 接收後才會移除。

message queue 的特性

Asynchronous Communications Protocol

非同步，這是 message queue 很大的特性。

Producers 傳送訊息至 Message Queue 之後不需要立即得到 response 以繼續處理其他事情。

舉例： Email，你在送出 email 之後不會特別去確認信件真的傳遞到對方信箱，而是會繼續去做其他事情。

message queue 的優勢

Better performance:

• 非同步溝通
• consumer 有空時才會處理 message
• 比起持續 polling 的方式相對有效率

Decouple 解耦性

• 將 publisher 與 consumer 進行 decouple 了，因此程式開發人員可以各自專心負責規模較小 & 單純的程式開發工作
• publisher 與 consumer 不需要知道雙方的實際的位置(例如：IP address)，只要將資料往 message queue 送就好
• break up apps && migrate to microservice

Reliablity

• queue 使 data 不易丟失
• 即使 consumer 短暫的無法提供服務也沒關係，message queue 可以將資料暫存起來，等待 consumer 重新上線時再送過去

Flexiability of scaling

• producer, queue, consumer 可以依照需求擴張或縮減

Message queue simple use case

Ｑ：假設你擁有一個 web service，每秒需要接受大量 request，request 不能被丟失，但 request 又要經過一個大量運算的 function 才能得到 response....

換句話說，你需要你的 server 可以保持在可以接收 request 的狀態，不被前一個 request block 住。

A：在 web service 跟 process service 中間加入 message queue。

而這樣的特性也讓 message queue 成為 microservice 服務間溝通的主流方式之一。

小結

這篇文章講述了 message queue 的基本概念、與其他訊息傳遞方式的異同、message queue 的優點與特性、message queue 的 simple use case，下篇文章將介紹常見的 message queue 服務 - RabbitMQ，讓我們可以更輕易的建構出 message queue 的架構，也介紹一些它獨有的一些功能。

團隊成員系列文

想盡辦法當好一個Junior Backend Developer
用舒服的姿勢開發 Python Project

參考連結

https://godleon.github.io/blog/ChatOps/message-queue-concepts/