【Message Queue - RabbitMQ】模型架構

對於軟體世界中Message Queue有興趣的朋友可以先閱讀這一篇「【資訊軟體知識】井然有序的處理機制 - Message Queue」建立基礎知識之後，再來看看這一篇會更容易進入情境唷！

這次就進入我們一般常見的MQ軟體「RabbitMQ」, 我們先以圖示來了解RabbitMQ的模型架構, 之後的章節再來逐一介紹如何去使用, 以及如何規劃與設計Queue的策略, 過程中皆以實作讓大家可以動手做並加深印象。

● Publisher: 負責生產訊息。

● Message: 由header跟body組成, 交換機主要根據header的內容來將訊息送到正確的Queue。

● Connection: 用於傳遞消息的TCP連接，因此也可以採用SSL來提升傳輸安全性。

● Channel: 在同一條TCP connection中可以建立許多的channel，不同的執行緒可以藉由使用不同的channel做出訊息隔離，同時又可以共用同一條TCP connection。

● Exchange: 主要負責將Message送往正確的Queues。

● BindingKey: Exchange與Queue之間建立關係的key。

● Queue: 消息隊列，儲存訊息的地方。

● Virtual Host: 主要達到資源隔離的效果，也用來做權限管理，一個Virtual Host裡面可以有多的Exchanges、Queues，而權限控制的單位則是Virtual Host，可以理解為每個用戶擁有自己的獨立資源。

俯瞰上面的架構圖搭配每個元件的介紹後, 從左而右很簡單, 就想像一下真實情境「郵件配送」的場景, 送件者(Publisher)將郵件(Message)透過各種渠道(臨櫃/郵筒)將郵件送至郵局(Broker), 而郵局則負責排序、分類, 依照距離、優先程度進行配送, 郵差會根據處理過後的訊息配送至各地區的收件箱, 而收件者(Consumer)則根據自己的時間去收件箱領取自己的信件, 這就是整個MQ模型的運行實例, 其實並不難, 只是將送與收進行分流有效率的處理, 避免等待造成擁塞, 包括現代的物流都有著MQ的影子, 所以MQ在傳輸上引入了不同的流程, 讓彼此不必等待, 值得我們好好的學習一番。

下一個章節將會談談如何將RabbitMQ以Docker架設, 讓我們在虛擬環境底下不管失敗多少次都能夠試誤到成功。

喜歡撰寫文章的你，不妨來了解一下：

Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 - 為什麼要加入？

歡迎加入一起練習寫作，賺取知識！