項目中要用到RabbitMQ，領導讓我先瞭解一下。在之前的公司中，用到過消息隊列MQ，阿裡的那款RocketMQ，當時公司也做了簡單的技術分享，自己也看了一些博客。自己在有道雲筆記上，做了一些整理，但後來也就擱在那了。現在有時間，就對MQ的一些簡單的概念做下整理吧。 RabbitMQ的一些介紹，請參 ...
項目中要用到RabbitMQ，領導讓我先瞭解一下。在之前的公司中，用到過消息隊列MQ，阿裡的那款RocketMQ，當時公司也做了簡單的技術分享，自己也看了一些博客。自己在有道雲筆記上，做了一些整理，但後來也就擱在那了。現在有時間，就對MQ的一些簡單的概念做下整理吧。
RabbitMQ的一些介紹，請參考https://www.jianshu.com/p/e55e971aebd8，裡面對一些概念和使用的講解還是非常詳細的。
什麼是消息隊列-定義
我們來看下維基百科上面的定義：
是一種進程間通信或同一進程的不同線程間的通信方式，軟體的軟體的貯列用來處理一系列的輸入，通常是來自用戶。
消息隊列提供了非同步的通信協議，每一個貯列中的紀錄包含詳細說明的數據，包含發生的時間，輸入設備的種類，以及特定的輸入參數。
也就是說：消息的發送者和接收者不需要同時與消息隊列交互。消息會保存在隊列中，知道接收者取回它。
下麵是架構圖：
Producer：消息生產者，負責生產和發送消息到Broker；
Broker：消息處理中心，負責消息存儲、確認、重試等；
Consumer：消息消費中心，負責從Broker中獲取消息並處理。
消息隊列-特性
非同步性：將耗時的同步任務通過發送消息的方式進行非同步處理，減少等待時間。
松耦合：不同系統、服務之間可以通過消息隊列進行通信，不用關心彼此的實現細節，數據格式一致。
分散式：為了防止消息堵塞，可以對消費者集群進行橫向擴展，避免單點故障，同樣隊列本身也可以。
可靠性：將接收到的消息落盤，就算伺服器重啟或者發生故障，恢復之後也能重新載入。
應用場景-簡單描述
根據特性，應用場景可以簡單描述為：
在處理高併發，而且不需要立即獲取結果的時候。
常用的消息隊列有：
RabbitMQ，RocketMQ，ActiveMQ，Kafka等。資料庫Redis或者MySQL也可以實現消息隊列模式。Redis實現消息隊列模式可以參考之前的一篇介紹Redis的隨筆
應用場景-非同步處理
應用場景-應用解耦
應用場景-限流削峰
應用場景-日誌處理
消息模式介紹-簡介
1、點對點模式：REQ/REP
最基本的模式，生產者發送一條消息，消費者去除並消費信息，給出響應後會從隊列中刪除該消息，所以不能重覆發送，只能被一個消費者消費。
2、發佈/訂閱模式：Pub/Sub
非常常見也是非常有用的一種模式，將發佈者與訂閱者進行解耦。發佈者只負責生產數據，而不需要關心誰是訂閱者，有多少訂閱者。類比於微信公眾號。
3、推/拉模式：Push/Pull
也是一種比較重要的模式，無論是Push端還是Pull端都可以做伺服器，綁定到特定的地址等待對方訪問。
如果我們在Push端綁定地址，那麼這是一個PushServer，對應的PullClient可以鏈接到這個PushServer往外拉數據；反之，如果建立一個PullServer，對應的PushClient就可以鏈接到PullServer並往裡面壓數據。
4、路由/代理模式：Router/Dealer
是一種典型的中間人模式，比較適用於多對多的網路當中，雙方在互相不認識的情況下達成共識並交易。類比於：顧客--->超時<--供應商。
使用TurboMQ的註意事項：
1、避免多線程處理消息，減少非同步請求，不要開多餘的Task去處理消息
2、減少無效的重覆推送，高併發下可以利用Redis做一些去重處理。
下圖是市場上的一些消息隊列MQ：
