什麼是訊息佇列？

訊息佇列，一般我們簡稱mq（也就是messges queue的意思）。這個名詞也很貼切它的技術實現，實現起來也就是訊息+佇列。

訊息，也就是一般我們業務的資料，理解起來比較簡單。

佇列，這就涉及到資料結構了。

佇列的資料結構想必不陌生了，它具有先進先出的特點。

這樣我們對訊息佇列就有很鮮明的解釋了：把訊息放到佇列裡，用佇列做儲存訊息的介質。

那麼訊息放在佇列中總有人需要來存入訊息和取訊息吧，這時候就引入兩個概念：生產者和消費者。

生成者負責投遞訊息到訊息佇列中。

消費者負責去訊息佇列中取訊息，也叫消費訊息。

那麼回歸到業務中，為什麼要使用到訊息佇列呢？

1、解耦

假設有a、b兩個業務介面，a呼叫b，但是某天b業務介面用不了了，a需要呼叫其他業務的介面，那麼這時a的**需要做修改，又又過了幾天，b介面又可以用了，a又需要呼叫b的介面或是其他介面都需要a去呼叫，這時a業務的**又改改改，a直接**說不幹了。。

這時候訊息佇列就派上用場了，在a業務和其他業務之間引入訊息佇列，a的呼叫可以寫到訊息佇列中去，然後其他業務作為消費者去消費訊息佇列中的訊息就可以了。a終於再也不用去改**了。。這就是解耦的好處。

2、非同步

非同步，在我們日常看來，就是把一件事情分開來處理，分別交給不同的人去做，一起完工。這樣的好處很明顯可以提高效率和減少處理事情的時間。

在程式設計的世界裡也是一樣的！假設有個業務流程是下單成功->簡訊通知->加使用者積分。在沒有非同步之前，這三個流程是一塊走的，也就是一步步往下走，好比如下單100ms，簡訊通知100ms，使用者積分100ms，總共300ms一次請求。

但是引入非同步！用訊息佇列去處理就不一樣了。

使用訊息佇列只需儲存下單成功的資訊，然後業務處理就變成下單完成後直接請求處理就完了直接耗時100ms，是不是很快？

那麼簡訊通知和加積分的介面就作為消費者去訊息佇列中取資料完成各自的業務，這樣就完成了非同步省時的操作！

3、削峰

訊息佇列又是如何完成削峰的呢？好比如你現在有兩台機器，每台只能處理1000個請求，那預估業務會來3000個請求你怎麼辦？削峰！把請求的流量高峰削掉，每台機器處理了1000個請求，剩下1000個請求先放到訊息佇列中，等機器根據自己處理請求的能力去訊息佇列去拿。

訊息資料會丟失嗎？

訊息如何實現高可用？

訊息會不會重複消費？

訊息可以保證順序消費嗎？

這些都是比較常見的問題，但是針對不同的mq不同的業務場景都有著不同的解決方案。筆者還會介紹一些相關的mq元件的內容以及常見問題。