1.1.1. 什麼是mq
mq(message queue)，從字面意思上看，本質是個佇列， fifo 先入先出，只不過佇列中存放的內容是message 而已，還是一種跨程序的通訊機制，用於上下游傳遞訊息。在網際網路架構中， mq 是一種非常常見的上下游「邏輯解耦+物理解耦」 的訊息通訊服務。使用了 mq 之後，訊息傳送上游只需要依賴 mq，不用依賴其他服務。
1.1.2. 為什麼要用mq
1.流量消峰
舉個例子，如果訂單系統最多能處理一萬次訂單，這個處理能力應付正常時段的下單時綽綽有餘，正常時段我們下單一秒後就能返回結果。但是在高峰期，如果有兩萬次下單作業系統是處理不了的，只能限制訂單超過一萬後不允許使用者下單。使用訊息佇列做緩衝，我們可以取消這個限制，把一秒內下的訂單分散成一段時間來處理，這時有些使用者可能在下單十幾秒後才能收到下單成功的操作，但是比不能下單的體驗要好。
2.應用解耦
以電商應用為例，應用中有訂單系統、庫存系統、物流系統、支付系統。使用者建立訂單後，如果耦合
呼叫庫存系統、物流系統、支付系統，任何乙個子系統出了故障，都會造成下單操作異常。當轉變成基於訊息佇列的方式後，系統間呼叫的問題會減少很多，比如物流系統因為發生故障，需要幾分鐘來修復。在這幾分鐘的時間裡，物流系統要處理的記憶體被快取在訊息佇列中，使用者的下單操作可以正常完成。當物流系統恢復後，繼續處理訂單資訊即可，中單使用者感受不到物流系統的故障，提公升系統的可用性。
3.非同步處理
有些服務間呼叫是非同步的，例如 a 呼叫 b， b 需要花費很長時間執行，但是 a 需要知道 b 什麼時候可以執行完，以前一般有兩種方式， a 過一段時間去呼叫 b 的查詢 api 查詢。或者 a 提供乙個 callback api，b 執行完之後呼叫 api 通知 a 服務。這兩種方式都不是很優雅，使用訊息匯流排，可以很方便解決這個問題，a 呼叫 b 服務後，只需要監聽 b 處理完成的訊息，當 b 處理完成後，會傳送一條訊息給 mq， mq 會將此訊息**給 a 服務。這樣 a 服務既不用迴圈呼叫 b 的查詢 api，也不用提供 callback api。同樣b 服務也不用做這些操作。 a 服務還能及時的得到非同步處理成功的訊息。
1.1.3. mq 的分類
1.activemq
優點：單機吞吐量萬級，時效性 ms 級，可用性高，基於主從架構實現高可用性，訊息可靠性較低的概率丟失資料。
缺點：官方社群現在對 activemq 5.x維護越來越少，高吞吐量場景較少使用。
2.kafka
大資料的殺手鐗，談到大資料領域內的訊息傳輸，則繞不開 kafka，這款為大資料而生的訊息中介軟體，以其百萬級 tps的吞吐量名聲大噪，迅速成為大資料領域的寵兒，在資料採集、傳輸、儲存的過程中發揮著舉足輕重的作用。目前已經被 linkedin， uber, twitter, netflix 等大公司所採納。
優點：效能卓越，單機寫入 tps 約在百萬條/秒，最大的優點，就是吞吐量高。時效性 ms 級可用性非
常高， kafka 是分布式的，乙個資料多個副本，少數機器宕機，不會丟失資料，不會導致不可用,消費者採用 pull 方式獲取訊息, 訊息有序, 通過控制能夠保證所有訊息被消費且僅被消費一次;有優秀的第三方kafkaweb 管理介面 kafka-manager；在日誌領域比較成熟，被多家公司和多個開源專案使用；功能支援： 功能較為簡單，主要支援簡單的 mq 功能，在大資料領域的實時計算以及日誌採集被大規模使用。
缺點： kafka 單機超過 64 個佇列/分割槽， load 會發生明顯的飆高現象，佇列越多， load 越高，傳送訊息響應時間變長，使用短輪詢方式，實時性取決於輪詢間隔時間，消費失敗不支援重試；支援訊息順序，但是一台**宕機後，就會產生訊息亂序，社群更新較慢。
3.rocketmq
rocketmq 出自阿里巴巴的開源產品，用 j**a 語言實現，在設計時參考了 kafka，並做出了自己的一些改進。被阿里巴巴廣泛應用在訂單，交易，充值，流計算，訊息推送，日誌流式處理， binglog 分發等場景。
優點：單機吞吐量十萬級,可用性非常高，分布式架構,訊息可以做到 0 丟失,mq 功能較為完善，還是分布式的，擴充套件性好,支援 10 億級別的訊息堆積，不會因為堆積導致效能下降,原始碼是 j**a 我們可以自己閱讀原始碼，定製自己公司的 mq。
缺點：支援的客戶端語言不多，目前是 j**a 及 c++，其中 c++不成熟；社群活躍度一般,沒有在mq核心中去實現 jms 等介面,有些系統要遷移需要修改大量**。
4.rabbitmq
2007 年發布，是乙個在amqp(高階訊息佇列協議)基礎上完成的，可復用的企業訊息系統，是當前最
主流的訊息中介軟體之一。
優點：由於 erlang 語言的高併發特性，效能較好；吞吐量到萬級， mq 功能比較完備,健壯、穩定、易用、跨平台、支援多種語言。如： python、 ruby、 .net、 j**a、 jms、 c、 php、actionscript、 xmpp、 stomp等，支援 ajax 文件齊全；開源提供的管理介面非常棒，用起來很好用,社群活躍度高；更新頻率相當高。
缺點：商業版需要收費,學習成本較高。
1.1.4. mq 的選擇
1.kafka
kafka 主要特點是基於pull 的模式來處理訊息消費，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸，適合產生大量資料的網際網路服務的資料收集業務。大型公司建議可以選用，如果有日誌採集功能，肯定是首選 kafka 了。
2.rocketmq
天生為金融網際網路領域而生，對於可靠性要求很高的場景，尤其是電商裡面的訂單扣款，以及業務削峰，在大量交易湧入時，後端可能無法及時處理的情況。 roketmq 在穩定性上可能更值得信賴，這些業務場景在阿里雙 11 已經經歷了多次考驗，如果你的業務有上述併發場景，建議可以選擇 rocketmq。
3.rabbitmq
結合 erlang 語言本身的併發優勢，效能好時效性微秒級，社群活躍度也比較高，管理介面用起來十分方便，如果你的資料量沒有那麼大，中小型公司優先選擇功能比較完備的 rabbitmq。
訊息佇列MQ
目錄 一 簡介 二 為什麼需要訊息佇列 mq 三 介紹 訊息佇列 message queuing 在電腦科學中，是一種程序間通訊或同一程序間不同執行緒的通訊方式。廣義上講訊息佇列是解決分布式系統中，各個功能模組間的資訊傳遞通訊方式。與檔案傳輸和rpc相比，訊息佇列具有更好的平台無關性，並能夠很好地支...
MQ訊息佇列
1.解耦 系統a將userid寫到訊息佇列中，系統c和系統d從訊息佇列中拿資料。這樣有什麼好處？系統a只負責把資料寫到佇列中，誰想要或不想要這個資料 訊息 系統a一點都不關心。即便現在系統d不想要userid這個資料了，系統b又突然想要userid這個資料了，都跟系統a無關，系統a一點 都不用改。系...
MQ訊息佇列應用
很榮幸，原來一直聽說的訊息佇列終於在前段時間用到了自己的專案中。為什麼會用到訊息佇列？毫無疑問，當然是傳輸訊息。這裡訊息一般是一串字串，當然，訊息的含義很多，可以是 hello world 可以是 你吃飯了嗎？可以是一串正式的xml報文。也可以是乙個txt檔案或者xml檔案 在用active mq的...