1. 消息隊列

1.1. MQ 的相關概念

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 出自阿里巴巴的開源產品，用 Java 語言實現，在設計時參考了 Kafka，并做出了自己的一些改進。被阿里巴巴廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理， binglog 分發等場景。

優點：單機吞吐量十萬級,可用性非常高，分布式架構,消息可以做到 0 丟失,MQ 功能較為完善，還是分布式的，擴展性好,支持 10 億級別的消息堆積，不會因為堆積導致性能下降,源碼是 java 我們可以自己閱讀源碼，定制自己公司的 MQ。

缺點： 支持的客戶端語言不多，目前是 java 及 c++，其中 c++不成熟；社區活躍度一般,沒有在MQ核心中去實現 JMS 等接口,有些系統要遷移需要修改大量代碼。

4.RabbitMQ

2007 年發布，是一個在AMQP(高級消息隊列協議)基礎上完成的，可復用的企業消息系統，是當前最
主流的消息中間件之一。

優點：由于 erlang 語言的高并發特性，性能較好； 吞吐量到萬級， MQ 功能比較完備,健壯、穩定、易用、跨平臺、 支持多種語言 。如： Python、 Ruby、 .NET、 Java、 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。