MQ 的相關概念
1. 什么是 MQ
MQ(message queue)，從字面意思上看，本質是個隊列，FIFO先入先出，只不過隊列中存放的內容是message而已，還是一種跨進程的通信機制，用於上下游傳遞消息。在互聯網架構中，MQ 是一種非常常見的上下游“邏輯解耦+物理解耦”的消息通信服務。使用了 MQ 之后，消息發送上游只需要依賴 MQ，不用依賴其他服務。
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 服務還能及時的得到異步處理成功的消息。
3. MQ 的分類
1.ActiveMQ
- 優點：單機吞吐量萬級，時效性 ms 級，可用性高，基於主從架構實現高可用性，消息可靠性較
低的概率丟失數據 - 缺點:官方社區現在對 ActiveMQ 5.x 維護越來越少，高吞吐量場景較少使用。
2.Kafka
- 大數據的殺手鐧，談到大數據領域內的消息傳輸，則繞不開 Kafka，這款為大數據而生的消息中間件，以其百萬級 TPS 的吞吐量名聲大噪，迅速成為大數據領域的寵兒，在數據采集、傳輸、存儲的過程中發揮着舉足輕重的作用。目前已經被
LinkedIn，Uber, Twitter, Netflix等大公司所采納。 - 優點: 性能卓越，單機寫入 TPS 約在百萬條/秒，最大的優點，就是吞吐量高。時效性 ms 級可用性非常高，kafka 是分布式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用,消費者采用 Pull 方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費且僅被消費一次;有優秀的第三方Kafka Web 管理界面 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 文檔齊全；開源提供的管理界面非常棒，用起來很好用,社區活躍度高；更新頻率相當高
- 官網：https://www.rabbitmq.com/
- 缺點：商業版需要收費,學習成本較高
4. MQ 的選擇
1.Kafka
- Kafka 主要特點是基於 Pull 的模式來處理消息消費，追求高吞吐量，一開始的目的就是用於日志收集和傳輸，適合產生大量數據的互聯網服務的數據收集業務。大型公司建議可以選用，如果有日志采集功能，肯定是首選 kafka 了。
2.RocketMQ
- 天生為金融互聯網領域而生，對於可靠性要求很高的場景，尤其是電商里面的訂單扣款，以及業務削峰，在大量交易涌入時，后端可能無法及時處理的情況。RoketMQ 在穩定性上可能更值得信賴，這些業務場景在阿里雙 11 已經經歷了多次考驗，如果你的業務有上述並發場景，建議可以選擇 RocketMQ。
3.RabbitMQ
- 結合 erlang 語言本身的並發優勢，性能好時效性微秒級，社區活躍度也比較高，管理界面用起來十分方便，如果你的數據量沒有那么大，中小型公司優先選擇功能比較完備的 RabbitMQ。