解耦、消峰、非同步
有abcd四個系統，a系統有一條資料需要傳給bcd，a系統不僅要關心資料傳送還要處理資料傳送bcd其中產生的異常，如b掛掉了怎麼辦，a是否重傳？如果使用訊息佇列，a系統只負責傳送訊息到訊息佇列，bcd消費訊息佇列中的訊息即可，a系統不關心訊息發給誰了，誰消費失敗了等等問題。
類似於地鐵排隊？（暴露了。。。），10000萬個併發請求直接到伺服器，伺服器最大處理能力2000個每秒，那樣極限情況下會有8000個請求在等待徵用系統資源，導致請求超時系統資源緊張、特別是後面有mysql資料庫等等問題。如果採用訊息佇列，8000個請求在訊息佇列裡，服務按照最大處理能力來消費佇列就可以。
有abcd四個系統，a系統接收到客戶請求把訊息傳送給訊息佇列，客戶得到乙個即時響應：「訊息已傳送」的響應。後續流程交給bcd去佇列處理。這樣客戶端街道的響應是同步響應，但實際的資料處理是非同步的。大大提高了客戶體驗和見笑了前置伺服器的壓力。還有種情況是a傳送請求到訊息佇列後，bcd的響應可以是並行的，這樣響應時間會大大降低，提高了效能。
特性activemq
rabbitmq
rocketmq
kafka
單機吞吐量
萬級，比 rocketmq、kafka 低乙個數量級
同 activemq
10 萬級，支撐高吞吐
10 萬級，高吞吐，一般配合大資料類的系統來進行實時資料計算、日誌採集等場景
topic 數量對吞吐量的影響
topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 rocketmq 的一大優勢，在同等機器下，可以支撐大量的 topic
topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，kafka 盡量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源
時效性ms 級
微秒級，這是 rabbitmq 的一大特點，延遲最低
ms 級
延遲在 ms 級以內
可用性高，基於主從架構實現高可用
同 activemq
非常高，分布式架構
非常高，分布式，乙個資料多個副本，少數機器宕機，不會丟失資料，不會導致不可用
訊息可靠性
有較低的概率丟失資料
基本不丟
經過引數優化配置，可以做到 0 丟失
同 rocketmq
功能支援
mq 領域的功能極其完備
基於 erlang 開發，併發能力很強，效能極好，延時很低
mq 功能較為完善，還是分布式的，擴充套件性好
功能較為簡單，主要支援簡單的 mq 功能，在大資料領域的實時計算以及日誌採集被大規模使用
架構設計原則 高併發
架構設計原則 高併發 高併發設計可以從以下幾方面考慮 1.無狀態 無狀態的應用容易進行水平擴充套件。實際常用 應用無狀態，配置檔案有狀態，例如，不同的機房讀取不同的配置檔案，通過配置中心指定。2.拆分 拆分維度 3.服務化 服務化需要考慮自動服務註冊，和服務發現，還有服務的分組 隔離，例如，有的系統...
高併發架構設計原則 拆分
在系統設計初期，是做乙個大而全的系統還是根據模組進行拆分要根據環境和需求進行權衡。訪問量不大 功能簡單 研發資源不多時可以做乙個大而全的系統即可 如果訪問量大資源充足 功能繁多可以考慮按功能拆分系統。下面幾種拆分維度 按照系統功能 業務拆分，比如商品系統 購物車系統 結算系統 訂單系統等。對乙個系統...
高併發架構設計原則 無狀態
服務端不儲存任何客戶端請求者資訊，客戶端的每次請求必須具備自述資訊，通過這些資訊識別客戶端身份。優點 客戶端請求不依賴服務端的資訊，任何多次請求不需要必須訪問到同一臺服務，這樣為伺服器橫向擴充套件提供了條件。服務端需要記錄每次繪畫的客戶端資訊，從而識別客戶端身份，根據客戶端身份進行對請求的處理，如s...