消息中間件入門

前言

本篇文章不涉及到代碼，只是站在理論的角度上去思考，整理，更清晰的認識消息隊列。

什麼是消息中間件

其實並無標準定義。通常認爲，消息中間件屬於分佈式系統中一個子系統，關注於數據的發送和接收，利用高效可靠的異步消息傳遞機制對分佈式系統中的其他各個子系統進行集成。

他的應用場景是什麼

1. 異步：
   好比如今有一個電商平臺下單的業務：用戶生成訂單以後點擊付款按鈕進行付款。這個操做對於後端的邏輯應該是這樣的：
   請求用戶服務進行帳戶扣款 ----> 調用訂單服務修改訂單表的訂單狀態 ----> 調用庫存服務扣減庫存數 ----> 調用積分服務給用戶增長積分 ----> 返回前端 「付款成功」的提示信息。
   這個邏輯是沒有問題的，可是仔細想一想，在服務器請求滿載的狀況下這麼一套流程跑下來要多久，若是你是用戶你能忍？那咱們如今就來優化一下這個過程。首先分析一下，用戶的請求是直接打在了用戶服務的，當支付接口調用成功以後就表示用戶的操做是沒問題的，付款也是成功的，那麼對於後續的修改訂單狀態、減庫存、加積分這些操做其實咱們能夠以異步的方式執行，不必非得一個一個排着隊執行，由於觸發這些操做的一個點是支付有沒有成功。
2. 解耦：
   仍是上面那個例子，當邏輯在增長積分那一步出現了問題，或者在新版本的迭代中積分服務的接口有變動，這時候在調用積分服務的時候就會出現異常，雖然說用戶付款成功了，可是響應前端的仍然是「支付失敗」，其實這是不合理的，積分能夠等一會再加，可是必定要保證用戶目前的支付業務是正常的，因此能夠把這些不相干的業務分離開，不進行接口的強制調用，要解耦但還要藕斷絲連，服務之間通訊進行消息的傳遞，當用戶付款成功以後就往隊列中發送一條付款成功的消息，其餘服務監聽到消息以後進行後續的業務處理，這樣就保證了對支付服務很小的影響。
3. 流量削峯：
   這個場景其實仍是很不錯的，假設如今有一個秒殺的功能，咱們服務端要作的是：
   一、保證高併發下服務仍然可用；
   二、保證商品不會超賣；
   仔細分析一下：秒殺這種業務是瞬時請求，秒殺未開始的時候請求也很正常，當準點一到，幾萬甚至幾十萬上億的請求忽然進來，可是最終能搶到商品的只有幾百或幾千個，那咱們爲何不能夠將瞬時的請求按照先來後到把併發請求變成串行請求呢，手速快的網速快的先進入隊列判斷商品庫存進行付款，後面手慢的就秒殺失敗了。

固然消息隊列的應用場景還有不少，分佈式事務，延時訂單的處理等高級用法，可是最經常使用的仍是以上三種場景。

既然消息隊列這麼好，那咱們乾脆都用它好了；其實否則，人無完人，有優勢也有缺點，下面咱們就來總結一下他的優缺點：

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存儲>關係型數據庫）

  ​

沒有坐享其成的工做,更沒有不勞而獲的收穫,若比別人貪心,請比別人用心。