業務無關，乙個具有普適性質的訊息佇列元件不需要考慮上層的業務模型，只做好訊息的分發就可以了，上層業務的不同模組反而需要依賴訊息佇列所定義的規範進行通訊。
fifo，先投遞先到達的保證是乙個訊息佇列和乙個buffer的本質區別。
容災，對於普適的訊息佇列元件來說，節點的動態增刪和訊息的持久化，都是支援其容災能力的重要基本特性。當然，這個特性對於遊戲伺服器中大部分應用中的訊息佇列來說不是必須的，這個也是跟應用情景有關的，很多時候沒有這種持久化的需求。
效能，這個不必多說了，訊息佇列的吞吐量上去了，整個系統的內部通訊效率也會有提高。
當系統**現「生產「和「消費「的速度或穩定性等因素不一致的時候，就需要訊息佇列，作為抽象層，彌合雙方的差異。「 訊息 」是在兩台計算機間傳送的資料單位。訊息可以非常簡單，例如只包含文字字串；也可以更複雜，可能包含嵌入物件。訊息被傳送到佇列中，「 訊息佇列 」是在訊息的傳輸過程中儲存訊息的容器 。
舉幾個例子
1）業務系統觸發簡訊傳送申請，但簡訊傳送模組速度跟不上，需要將來不及處理的訊息暫存一下，緩衝壓力。就可以把簡訊傳送申請丟到訊息佇列，直接返回使用者成功，簡訊傳送模組再可以慢慢去訊息佇列中取訊息進行處理。
2）調遠端系統下訂單成本較高，且因為網路等因素，不穩定，攢一批一起傳送。
3）任務處理類的系統，先把使用者發起的任務請求接收過來存到訊息佇列中，然後後端開啟多個應用程式從佇列中取任務進行處理。
使用了訊息佇列，生產者一方，把訊息往佇列裡一扔，就可以立馬返回，響應使用者了。無需等待處理結果。
處理結果可以讓使用者稍後自己來取，如醫院取化驗單。也可以讓生產者訂閱（如：留下手機號碼或讓生產者實現listener介面、加入監聽佇列），有結果了通知。獲得約定將結果放在某處，無需通知。
考慮電商系統下訂單，傳送資料給生產系統的情況。電商系統和生產系統之間的網路有可能掉線，生產系統可能會因維護等原因暫停服務。如果不使用訊息佇列，電商系統資料發布出去，顧客無法下單，影響業務開展。兩個系統間不應該如此緊密耦合。應該通過訊息佇列解耦。同時讓系統更健壯、穩定。
非同步化、解耦、消除峰值
以上三點其實可以用乙個例子來解釋——設想有一款mmo遊戲，沒有人肉寫的快取層或者orm，所有邏輯節點都直連mysql，邏輯節點內除了要關注場景、戰鬥、互動等複雜邏輯以外，還要有個拼sql語句的模組，想想簡直是蛋疼。先考慮一下這樣設計的弊端所在：
1. 邏輯節點與db的互動會有大量io，即使把與db互動的模組耦合在邏輯節點內，其實現對你來說是黑盒，如果內部是同步實現的，那就直接卡你遊戲主邏輯，就因為一次存檔操作，玩家們都掉線了，伺服器也可以關掉了。
2. 那麼我們改進一下，針對1的情況，可以把這個模組做到乙個執行緒裡掛在邏輯節點上。這樣其實邏輯節點跟這個db前端模組的互動就會基於乙個比較原始的訊息佇列。但是這樣還有乙個壞處，那就是這兩種任務一種是計算密集的（玩家的邏輯處理）、一種是io密集的（只負責寫入讀取mysql），搞到乙個節點中，擴充套件起來會非常麻煩，而且耦合度太高。比如說現在發現場景放單節點上有瓶頸，要按場景分節點，那麼這種掛在上面的資料模組怎麼跟其他場景的互動呢？
3. 峰值的問題。在分布式系統中，一次分布式事務關聯的是多個節點，其中每乙個節點出現問題都會成為整個事務處理流程中的瓶頸。如果邏輯節點與資料庫之間沒有乙個起到緩衝作用的節點，那就是每次操作都要訪問資料庫，對於mmo來說，乙個玩家上線load幾百k資料，乙個服10萬個玩家上線已經足夠搞垮乙個mysql節點了。如果直接搞垮還是比較好的結果，至少是前面的玩家確實登入上去了並且可以正常遊戲，後面的玩家登入不上。但是很可惜，十年前開始流行的c10k說法就是在講：併發量上來之後，會造成chain reaction，大量的併發不會直接掛掉你的mysql節點，但是會拖慢速度，降低吞吐量，乙個玩家的請求由於處理時間太長，導致玩家放棄重試，但是對於後端來說，對該玩家之前的處理過程消耗的資源就全部浪費了，陷入惡性迴圈。
所以，這種情景下，乙個介於邏輯節點和db節點之間的快取節點就是理所當然的事情了。這個快取節點其實很多時候也可以看作是乙個更複雜的訊息佇列節點。
訊息佇列中的資料需要在多個系統間共享資料才能發揮價值。所以必須提供分布式通訊機制、協同機制。
單系統內部，為了更好的效能、為了避免單點故障，多為集群環境。集群環境中，應用執行在多台伺服器的多個jvm中；資料也儲存在各種型別的資料庫或非資料庫的多個節點上。為了滿足多節點協作需要，需要提供分布式的解決方案。
需進行良好的併發控制。確保「執行緒安全「。不要出現乙個訂單被出貨兩次。不要出現顧客a下的單，發貨發給了顧客b等情況。
需定義簡單的，語義明確的，業務無關的，恰當穩妥的統一的訪問方式。
控制好單點故障，確保資料安全。
可便捷擴容。
成熟的訊息佇列中介軟體產品太多了，族繁不及備載。成熟產品經過驗證，介面規範，可擴充套件性強。
結合事業環境因素、組織過程遺產、實施運維考慮、技術路線考慮、開發人員情況等原因綜合考慮。
為什麼需要訊息佇列，及使用訊息佇列的好處？
一 訊息佇列的特性 業務無關，乙個具有普適性質的訊息佇列元件不需要考慮上層的業務模型，只做好訊息的分發就可以了，上層業務的不同模組反而需要依賴訊息佇列所定義的規範進行通訊。fifo，先投遞先到達的保證是乙個訊息佇列和乙個buffer的本質區別。容災，對於普適的訊息佇列元件來說，節點的動態增刪和訊息的...
訊息佇列 01 為什麼需要訊息佇列）
主要功能就是收發訊息，但不僅僅是解決應用之間的通訊問題eg.秒殺系統 流程 風險控制 庫存鎖定 生成訂單 簡訊通知 更新統計資料 使用訊息佇列伺服器只需要先實現風控和庫存鎖定 好處 更快返回結果 減少等待，提公升系統功能 健壯框架設計思路 使用訊息佇列隔離閘道器和後端服務，以達到流量控制和保護後端服...
01 為什麼需要訊息佇列？
對於對於這 5 個步驟來說，能否決定秒殺成功，實際上只有風險控制和庫存鎖定這 2 個步驟。只要使用者的秒殺請求通過風險控制，並在服務端完成庫存鎖定，就可以給使用者返回秒殺結果了，對於後續的生成訂單 簡訊通知和更新統計資料等步驟，並不一定要在秒殺請求中處理完成。令牌發生器按照預估的處理能力，勻速生產令...