基于Redis實作分布式消息隊列（1）基于Redis實作分布式消息隊列（1）1、為什麼需要消息隊列？2、使用消息隊列有什麼好處？3、為什麼需要分布式？4、分布式環境下需要解決哪些問題5、如何實作？

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

舉個例子：業務系統觸發短信發送申請，但短信發送子產品速度跟不上，需要将來不及處理的消息暫存一下，緩沖壓力。

再舉個例子：調遠端系統下訂單成本較高，且因為網絡等因素，不穩定，攢一批一起發送。

再舉個例子，互動子產品5：00到24：00和電商系統聯通，和内部ERP斷開。1：00到4：00和ERP聯通，和電商系統斷開。

再舉個例子，服務員點菜快，廚師做菜慢。

再舉個例子，到銀行辦事的人多，提供服務的視窗少。

乖乖排隊吧。

使用了消息隊列，生産者一方，把消息往隊列裡一扔，就可以立馬傳回，響應使用者了。無需等待處理結果。

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

考慮電商系統下訂單，發送資料給生産系統的情況。

電商系統和生産系統之間的網絡有可能掉線，生産系統可能會因維護等原因暫停服務。

如果不使用消息隊列，電商系統資料釋出出去，顧客無法下單，影響業務開展。

兩個系統間不應該如此緊密耦合。應該通過消息隊列解耦。同時讓系統更健壯、穩定。

消息隊列中的資料需要在多個系統間共享資料才能發揮價值。

是以必須提供分布式通信機制、協同機制。

單系統内部，為了更好的性能、為了避免單點故障，多為叢集環境。

叢集環境中，應用運作在多台伺服器的多個JVM中；資料也儲存在各種類型的資料庫或非資料庫的多個節點上。

為了滿足多節點協作需要，需要提供分布式的解決方案。

需進行良好的并發控制。確定“線程安全“。

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

需定義簡單的，語義明确的，業務無關的，恰當穩妥的統一的通路方式。

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

可便捷擴容。

成熟的消息隊列中間件産品太多了，族繁不及備載。

成熟産品經過驗證，接口規範，可擴充性強。

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

如何做呢？

請聽下回分解。