高級開發人員必備技術：MQ

也許在大家公司從沒有使用過MQ，也不知道這東西是用來幹什麼的，可是一旦你進入大公司你就會發現，這東西到處可見。今天就來講說MQ方面的東西，我公衆號有 activemq的 demo，你們能夠本身去看看。

什麼是MQ

Message Queue簡稱MQ，中文消息隊列。

• 「消息」是在兩臺計算機間傳送的數據單位。消息能夠很是簡單，例如只包含文本字符串；也能夠更復雜，可能包含嵌入對象。
• 消息被髮送到隊列中。「消息隊列」是在消息的傳輸過程當中保存消息的容器。消息隊列管理器在將消息從它的源中繼到它的目標時充當中間人。隊列的主要目的是提供路由並保證消息的傳遞；若是發送消息時接收者不可用，消息隊列會保留消息，直到能夠成功地傳遞它。

你能夠把它理解爲一箇中間件，幫你完成多個系統或應用間的消息傳遞。

爲何要使用MQ

首先它有３個核心，解耦,異步,削峯，所以咱們能夠想到如下使用場景：

• 你的系統要和多個系統發生關係，別的系統要從你這獲取一些數據，今天A系統和你要這樣的數據，明天Ｂ系統說你的數據有問題，後天Ｃ系統讓你加個別的數據。你一我的要維護解決不少問題，忙得不可開交。而有了ＭＱ，你就能夠經過Pub/Sub 發佈訂閱消息這麼一個模型，系統就跟其它系統完全解耦了。只要把消息放到隊列裏，其它系統就本身去處理本身須要的數據，本身再也不考慮該給誰發送數據。好比：下完訂單，再也不去通知庫存作同步處理。把該物品的信息放在隊列中，庫存本身去選擇何時去處理計算本身的庫存。
• 仍是上面的例子，以前的流程，ｕｓｅｒ瀏覽器端發起購物請求３ｍｓ，訂單系統處理數據庫３００ｍｓ，以後庫存系統處理數據庫３００ｍｓ，這樣同步狀況下加起來就要６０３ｍｓ。即便前端有加載提示框，等待時間超過３００ｍｓ，人眼是能感覺到這種延遲的，體驗很很差，速度越快才能留住ｕｓｅｒ。如今使用ＭＱ採用異步消息處理，假如消息放進隊列須要３ｍｓ，那麼最終的響應時間是３＋３＝６ｍｓ，對於建立訂單和庫存計算ｕｓｅｒ並不關心，這樣極大的提升了響應時間。
• 一個大的網站或是應用，總會迎來訪問量的高峯，多是營銷活動忽然帶來的大流量，或是節假日。好比雙十一，購物人數忽然猛增，併發數提升，數據庫的壓力忽然增大，超出了每秒鐘的處理能力，就會致使網站癱瘓。使用ｍｑ後，數據庫能夠沒必要立馬處理這麼多的請求，能夠本身選擇能承受的消息慢慢去處理。全部的消息積壓在隊列中，而不是同時積壓到數據庫。加入隊列中積壓了１億條數據，而個人數據庫只能每秒處理１００萬條數據，那我就每秒從隊列中取出１００萬條來處理，始終不會超出閾值，這樣數據庫就不會被擠垮。把峯值慢慢消耗。

如今想一想你爲何沒有使用到ｍｑ吧？或是考略使用ｍｑ

使用後帶來的威脅

任何事物都有它的兩面性，既然有優勢那也有缺點：

• 系統可用性下降

萬一ｍｑ掛了，隊列裏面的數據沒有了，其它系統數據還沒處理完，這可咋整？

• 系統的複雜度提升了

你用個ｍｑ是爽了，其它系統也要對應的修改本身的系統，來消費隊列中的消息。硬生生加個 MQ 進來，你怎麼保證消息沒有重複消費？怎麼處理消息丟失的狀況？怎麼保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。

• 一致性問題

你訂單系統操做成功了，可是庫存系統卻失敗了，這樣致使了數據的不一致。

因此消息隊列實際是一種很是複雜的架構，你引入它有不少好處，可是也得針對它帶來的壞處作各類額外的技術方案和架構來規避掉，作好以後，你會發現，媽呀，系統複雜度提高了一個數量級，也許是複雜了 10 倍。可是關鍵時刻，用，仍是得用的。

主流的MQ產品

• Kafka
• ActiveMQ
• RabbitMQ

特性	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 功能，在大數據領域的實時計算以及日誌採集被大規模使用

上面表格來自：https://github.com/doocs/adva...

推薦使用

• 早期你們都在使用ActiveMQ ，適合小型項目，若是你嘗試使用ＭＱ，你能夠選擇。
• RabbitMQ社區活躍度比較高，開源，有問題能夠在社區尋求幫助。可是底層使用了erlang 語言，不是小公司又能力掌控的　。
• RocketMQ 阿里出品，是用的中國公司比較多，經歷過使用場景的考驗，且自家產品也在用，不用擔憂。可是社區活躍度不高。推薦使用。
• 若是是大數據領域的實時計算、日誌採集等場景，用 Kafka 是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，況且幾乎是全世界這個領域的事實性規範。
• 因此中小型公司，技術實力較爲通常，技術挑戰不是特別高，用 RabbitMQ 是不錯的選擇；大型公司，基礎架構研發實力較強，用 RocketMQ 是很好的選擇。