Github倉庫地址：
https://github.com/imtudou/imtudou.microservices/tree/master/net/samples/rabbitmq
什麼是消息中間件
MQ(message queue)，從字面意思上看，本質是個隊列，FIFO 先入先出，只不過隊列中存放的內容是 message 而已，還是一種跨進程的通信機制，用於上下游傳遞消息。在互聯網架構中，MQ 是一種非常常 見的上下游“邏輯解耦+物理解耦”的消息通信服務。使用了 MQ 之後，消息發送上游只需要依賴 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 服務還能及時的得到異步處理成功的消息。
消息中間件的分類
| 優點 | 缺點 | |
|---|---|---|
| ActiveMQ | 單機吞吐量萬級，時效性 ms 級，可用性高，基於主從架構實現高可用性，消息可靠性較 低的概率丟失數據 |
官方社區現在對 ActiveMQ 5.x 維護越來越少，高吞吐量場景較少使用。 |
| Kafka | 大數據而生，百萬級 TPS，吞吐量高，在大數據領域的實時計算以及日誌採集被大規模使用 | Kafka 單機超過 64 個隊列/分區，Load 會發生明顯的飆高現象，隊列越多，load 越高，發送消 息響應時間變長，使用短輪詢方式，實時性取決於輪詢間隔時間，消費失敗不支持重試；支持消息順序， 但是一臺代理宕機後，就會產生消息亂序，社區更新較慢； |
| RocketMQ | 阿里出品，單機吞吐量十萬級,可用性非常高，分佈式架構,消息可以做到 0 丟失,MQ 功能較爲完善，還是分 布式的，擴展性好,支持 10 億級別的消息堆積，不會因爲堆積導致性能下降,源碼是 java 我們可以自己閱 讀源碼，定製自己公司的 MQ |
支持的客戶端語言不多，目前是 java 及 c++，其中 c++不成熟；社區活躍度一般,沒有在MQ 核心中去實現 JMS 等接口,有些系統要遷移需要修改大量代碼 |
| RabbitMQ | 2007 年發佈，是一個在AMQP(高級消息隊列協議)基礎上完成的，可複用的企業消息系統，是當前最 主流的消息中間件之一。 由於 erlang 語言的高併發特性，性能較好；吞吐量到萬級，MQ 功能比較完備,健壯、穩定、易 用、跨平臺、支持多種語言 如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX 文檔齊全；開源提供的管理界面非常棒，用起來很好用,社區活躍度高；更新頻率相當高 |
商業版需要收費,學習成本較高 |
消息中間件的選擇
1.Kafka
Kafka 主要特點是基於Pull 的模式來處理消息消費，追求高吞吐量，一開始的目的就是用於日誌收集 和傳輸，適合產生大量數據的互聯網服務的數據收集業務。大型公司建議可以選用，如果有日誌採集功能， 肯定是首選 kafka 了。
2.RocketMQ
天生爲金融互聯網領域而生，對於可靠性要求很高的場景，尤其是電商裏面的訂單扣款，以及業務削 峯，在大量交易湧入時，後端可能無法及時處理的情況。RoketMQ 在穩定性上可能更值得信賴，這些業務 場景在阿里雙 11 已經經歷了多次考驗，如果你的業務有上述併發場景，建議可以選擇 RocketMQ。
3.RabbitMQ
結合 erlang 語言本身的併發優勢，性能好時效性微秒級，社區活躍度也比較高，管理界面用起來十分 方便，如果你的數據量沒有那麼大，中小型公司優先選擇功能比較完備的 RabbitMQ。
RabbitMQ名詞解釋
vhost：虛擬主機，一個broker裏可以開設多個vhost用做不同用戶的權限分離，多租戶設置
Broker：消息隊列服務器實體
Exchange：消息交換機，指定消息按照什麼規則，路由到那個隊列
Queue：消息對列的載體，每個消息都會被投入到一個或多個隊列
Binding：綁定，它的作用就是把exchnage和queue按照路由規則綁定起來
RoutingKey：路由關鍵字，exchange根據這個關鍵字進行消息投遞
Producer：消息生產者，投遞消息的程序
Consumer：消息消費者，接受消息的程序
Channel：消息通道，在客戶端的每個連接裏面可以建立多個channel，每個channel代表一個會話任務，作爲輕量級的Connection極大減少了操作系統建立TCPconnection的開銷
