1、為什麼需要訊息佇列？

當系統中出現“生產“和“消費“的速度或穩定性等因素不一致的時候，就需要訊息佇列，作為抽象層，彌合雙方的差異。

舉個例子：業務系統觸發簡訊傳送申請，但簡訊傳送模組速度跟不上，需要將來不及處理的訊息暫存一下，緩衝壓力。
再舉個例子：調遠端系統下訂單成本較高，且因為網路等因素，不穩定，攢一批一起傳送。
再舉個栗子，互動模組5：00到24：00和電商系統聯通，和內部ERP斷開。1：00到4：00和ERP聯通，和電商系統斷開。
再舉個例子，服務員點菜快，廚師做菜慢。
再舉個例子，到銀行辦事的人多，提供服務的視窗少。
乖乖排隊吧。

2、使用訊息佇列有什麼好處？

2.1、提高系統響應速度

使用了訊息佇列，生產者一方，把訊息往佇列裡一扔，就可以立馬返回，響應使用者了。無需等待處理結果。

處理結果可以讓使用者稍後自己來取，如醫院取化驗單。也可以讓生產者訂閱（如：留下手機號碼或讓生產者實現listener介面、加入監聽佇列），有結果了通知。獲得約定將結果放在某處，無需通知。

2.2、提高系統穩定性

考慮電商系統下訂單，傳送資料給生產系統的情況。
電商系統和生產系統之間的網路有可能掉線，生產系統可能會因維護等原因暫停服務。

如果不使用訊息佇列，電商系統資料釋出出去，顧客無法下單，影響業務開展。
兩個系統間不應該如此緊密耦合。應該通過訊息佇列解耦。同時讓系統更健壯、穩定。

3、為什麼需要分散式？

3.1、多系統協作需要分散式

訊息佇列中的資料需要在多個系統間共享資料才能發揮價值。
所以必須提供分散式通訊機制、協同機制。

3.2、單系統內部署環境需要分散式

單系統內部，為了更好的效能、為了避免單點故障，多為叢集環境。
叢集環境中，應用執行在多臺伺服器的多個JVM中；資料也儲存在各種型別的資料庫或非資料庫的多個節點上。
為了滿足多節點協作需要，需要提供分散式的解決方案。

4、分散式環境下需要解決哪些問題

4.1、併發問題

需進行良好的併發控制。確保“執行緒安全“。

不要出現一個訂單被出貨兩次。不要出現顧客A下的單，發貨發給了顧客B等情況。

4.2、簡單的、統一的操作機制

需定義簡單的，語義明確的，業務無關的，恰當穩妥的統一的訪問方式。

4.3、容錯

控制好單點故障，確保資料安全。

4.4、可橫向擴充套件

可便捷擴容。

5、如何實現？

成熟的訊息佇列中介軟體產品太多了，族繁不及備載。

成熟產品經過驗證，介面規範，可擴充套件性強。

結合事業環境因素、組織過程遺產、實施運維考慮、技術路線考慮、開發人員情況等原因綜合考慮，基於Redis自己做一個是最可行的選擇。

如何做呢？
請聽下回分解。