Message Queue (MQ) 消息队列 概念简介
Message Queue (MQ)，時常翻譯為「訊息佇列」或「消息隊列」，常見的開源選擇有 RabbitMQ、Kafka 和今天要談的 NATS。
Message Queue 本身可以簡單想像成是一個服務級別的 Queue，同樣訊息先進先出，差別在因為這是獨立的服務，所以通常必須異步處理；另一個分別是通常 Queue 是一進一出，一則訊息被一個消費者接收，另一個就收不到，但 Message Queue 可以做到讓每個消費者都能收到全部的訊息(這通常是可選的)。
MQ 概念上大致可以分为兩個角色，分別是：
生產者 (Producer)
消費者 (Consumer)
生產者負責生產訊息 (Message)，並丟進 MQ，而消費者負責接收並處理訊息。兩者可以完全不用知道對方，只要和 MQ 溝通即可。
換句話說，只要生產者產生的訊息符合消費者能接收的格式，那麼其實不一定具體非得由哪個生產者才能生產。因為無論是單個生產者還是多個不同的生產者，對身為接收端的消費者都無所謂，只要能正常收到符合條件格式的訊息即可。
反過來也是如此，生產者只管生產，至於後端究竟有多少個消費者消費，對生產者來說無關緊要，也不會影響程式碼，可以讓生產者和消費者各自都擁有最大的彈性。
套用我流解釋，使用 MQ 可以有幾個好處：
更簡單
更可靠
更大更強
更簡單- 程式簡化和解耦
使用 MQ 可以方便讓不同服務解耦，正如前面所說，所有服務不管是生產者還是消費者 ，全部都統一都只和 MQ 溝通，生產者不用管是誰處理或是什麼時候處理，而消費者也不用管是誰生產的內容。
因此無論是生產者還是消費者都可以自由的拆分成多個服務，讓每個服務都只負責一件事，程式碼可以很單純。
也就是說只要能和 MQ 溝通，不管是用什麼程式語言、用什麼方式處理皆無所謂，就算後面其實是一隻雞在處理也可以。
你永遠不會知道網路上和你聊天的是不是一隻雞，但如果他真的能用你理解的方式溝通、協作，那對方是不是只是一隻雞其實也沒差了。
更進一步說，其實連時間也解耦了，因為中間隔了一層 MQ，所以不一定需要生產者和消費者同時在線上。
生產者在生產訊息時，沒人規定消費者非得即時在線上處理；反之亦然，消費者在處理訊息時，生產者也不一定要同時在線上生產訊息。
更可靠 - 服務掛掉也沒差的能力
在這個架構下，因為生產者或消費者不需要直接連結，所以即使服務掛掉，系統還能一定程度的繼續運作。
因為 MQ 通常都有一定程度的儲存訊息的能力，所以即使某一個消費者掛掉，也可以等到它復活後再繼續把之前沒推送成功的訊息再推送給它。
雖然處理時間多少會受影響，但至少訊息不會掉，在多數情境下，這樣也不會影響到系統的運作。
更大更強 - 大流量的緩衝
網路服務的流量並不一定是恆定的，系統有時可能會突然面臨超大量的網路請求，但是即使要開更多台服務器也需要一點時間，這時 MQ 就可以當作「漏斗」一樣的功能，充當緩充。
等到足夠數量的服務啟動完畢，可以跟上訊息生產的速度了，就可以處理之前來不及處理的訊息了。
注意
另一種假設是這類超大量的網路請求不會一直持續，所以如果業務許可，也可以選擇不啟動新的服務器，讓 MQ 先接收下來就好，之後再讓消費者慢慢消化，用時間換取資源，也是一種選擇。
共 0 条评论