前言 本篇文章不涉及到代碼，只是站在理論的角度上去思考，整理，更清晰的認識消息隊列。 什麼是消息中間件 其實並沒有標准定義。一般認為，消息中間件屬於分散式系統中一個子系統，關註於數據的發送和接收，利用高效可靠的非同步消息傳遞機制對分散式系統中的其餘各個子系統進行集成。 他的應用場景是什麼 非同步： 比如 ...
前言
本篇文章不涉及到代碼，只是站在理論的角度上去思考，整理，更清晰的認識消息隊列。
什麼是消息中間件
其實並沒有標准定義。一般認為，消息中間件屬於分散式系統中一個子系統，關註於數據的發送和接收，利用高效可靠的非同步消息傳遞機制對分散式系統中的其餘各個子系統進行集成。
他的應用場景是什麼
- 非同步：
比如現在有一個電商平臺下單的業務：用戶生成訂單之後點擊付款按鈕進行付款。這個操作對於後端的邏輯應該是這樣的：
請求用戶服務進行賬戶扣款 ----> 調用訂單服務修改訂單表的訂單狀態 ----> 調用庫存服務扣減庫存數 ----> 調用積分服務給用戶增加積分 ----> 返回前端 “付款成功”的提示信息。
這個邏輯是沒有問題的，但是仔細想想，在伺服器請求滿載的情況下這麼一套流程跑下來要多久，如果你是用戶你能忍？那我們現在就來優化一下這個過程。首先分析一下，用戶的請求是直接打在了用戶服務的，當支付介面調用成功之後就表示用戶的操作是沒問題的，付款也是成功的，那麼對於後續的修改訂單狀態、減庫存、加積分這些操作其實我們可以以非同步的方式執行，沒必要非得一個一個排著隊執行，因為觸發這些操作的一個點是支付有沒有成功。 - 解耦：
還是上面那個例子，當邏輯在增加積分那一步出現了問題，或者在新版本的迭代中積分服務的介面有變更，這時候在調用積分服務的時候就會出現異常，雖說用戶付款成功了，但是響應前端的仍然是“支付失敗”，其實這是不合理的，積分可以等一會再加，但是一定要保證用戶目前的支付業務是正常的，所以可以把這些不相干的業務分離開，不進行介面的強制調用，要解耦但還要藕斷絲連，服務之間通信進行消息的傳遞，當用戶付款成功之後就往隊列中發送一條付款成功的消息，其他服務監聽到消息之後進行後續的業務處理，這樣就保證了對支付服務很小的影響。 - 流量削峰：
這個場景其實還是很不錯的，假設現在有一個秒殺的功能，我們服務端要做的是：
1、保證高併發下服務仍然可用；
2、保證商品不會超賣；
仔細分析一下：秒殺這種業務是瞬時請求，秒殺未開始的時候請求也很正常，當準點一到，幾萬甚至幾十萬上億的請求突然進來，但是最終能搶到商品的只有幾百或幾千個，那我們為什麼不可以將瞬時的請求按照先來後到把併發請求變成串列請求呢，手速快的網速快的先進入隊列判斷商品庫存進行付款，後面手慢的就秒殺失敗了。
當然消息隊列的應用場景還有很多，分散式事務，延時訂單的處理等高級用法，但是最常用的還是以上三種場景。
既然消息隊列這麼好，那我們乾脆都用它好了；其實不然，人無完人，有優點也有缺點，下麵我們就來總結一下他的優缺點：
- 系統的技術複雜度變高了，要考慮消息的可靠性消費，解決重覆消費和消息丟失的問題。
- 無法做到實時性，如果系統對於數據實時性要求很高的話，消息隊列顯然就顯的有點多餘了。
什麼是RabbitMQ
什麼是RabbitMQ呢？鑒用百度的一句話：
RabbitMQ是實現了高級消息隊列協議（AMQP）的開源消息代理軟體（亦稱面向消息的中間件）。RabbitMQ伺服器是用Erlang語言編寫的，而集群和故障轉移是構建在開放電信平臺框架上的。所有主要的編程語言均有與代理介面通訊的客戶端庫。
那麼AMQP又是什麼呢？為了好理解，我就不套用百度了，簡單來說AMPQ應用層協議的一個開放標準,，它制定了一套規範的消息伺服器的模型，可以由不同的中間件去實現它，是為面向消息的中間件設計。基於此協議的客戶端與消息中間件可傳遞消息，並不受客戶端/中間件不同產品，不同的開發語言等條件的限制。目標是實現一種在全行業廣泛使用的標準消息中間件技術，以便降低企業和系統集成的開銷，並且向大眾提供工業級的集成服務，主要實現有RabbitMQ。
再用簡單的話解釋一下RabbitMQ：他是一個系統之間以解耦和非同步的方式進行邏輯交互的一個中間平臺，使用Erlang語言實現，系統之間可以不進行強依賴，只需要保證這個中間平臺可以成功的將消息進行傳遞即可。
當然，消息中間件也不只有RabbitMQ，還有其他的比如：RocketMQ、Kafka、ActiveMQ、還有好多。。。。。
那麼相比之下RabbitMQ的地位如何呢？看下圖：
技術選型
實際工作中對於各種MQ的技術選型個人認為是這樣的：
-
用戶訪問量在ActiveMQ 的可承受範圍內，而且確實主要是基於解耦和非同步來用的，可以考慮ActiveMQ，也比較貼近Java
工程師的使用習慣，但是ActiveMQ 現在停止維護了，同時ActiveMQ 併發不高，所以業務量一定的情況下可以考慮使用。 -
RabbitMQ 作為一個純正血統的消息中間件，有著高級消息協議AMQP 的完美結合，在消息中間件中地位無可取代，但是erlang
語言阻止了我們去深入研究和掌控，對公司而言，底層技術無法控制，但是確實是開源的，有比較穩定的支持，活躍度也高。 -
對自己公司技術實力有絕對自信的，可以用RocketMQ，但是RocketMQ誕生比較晚，並且更新迭代很快，這個意味著在使用過程中有可能會遇到很多坑，所以如果你們公司Java 技術不是很強，不推薦使用。
-
中小型公司，技術實力較為一般，技術挑戰不是特別高，用ActiveMQ、RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇
-
如果是大數據領域的實時計算、日誌採集等場景，用Kafka 是業內標準的，絕對沒問題，社區活躍度很高，幾乎是全世界這個領域的事實性規範。
-
從性能上來看，使用文件系統的消息中間件（Kafka、RokcetMq）性能是最好的，所以基於文件系統存儲的消息中間件是發展趨勢。（從存儲方式和效率來看文件系統>KV存儲>關係型資料庫）
沒有不勞而獲的工作,更沒有坐享其成的收穫,若比別人貪心,請比別人用心。
