訊息匯流排Bus介紹及使用場景-訊息佇列和RabbitMQ介紹及安裝

接上一章配置中心實戰（十七），明顯的缺點所在，雖然Config-server拉取配置，服務獲取Config-server配置，但無法感知到配置的修改，也就是動態更新

什麼是訊息？

一個事件，需要廣播或單獨傳遞給某個介面

為什麼使用這個？

配置更新了，但是其它系統不知道是否更新

訊息佇列

就是一個存放訊息的容器，把要傳輸的資料放在佇列裡，實際應用場景有解耦、非同步、削峰

應用解耦：比如A系統傳送資料到BCD三個系統，通過介面傳送，如果此時出現E系統也需要這個資料呢？如果C系統又不使用呢？在這種情況下系統耦合，A系統產生一條關鍵資料還要考慮BCDE四個系統如果掛掉了還要不要重發，要不要把訊息存起來。
如果使用MQ，A系統產生一條資料，傳送到MQ裡面，那個系統需要資料去MQ裡面消費，如果不需要就取消對MQ的消費即可。通過Pub/Sub釋出訂閱訊息這麼一個模型，A系統就可和其它系統徹底解耦，多應用間通過訊息佇列對同一訊息進行處理，避免呼叫介面失敗導致整個過程失敗

非同步處理：比如A系統在自己本地運算，還需要再BCD三個系統呼叫，自己本地寫要3ms，BCD分別寫庫時間加起來要1s，一般網際網路企業，對於使用者操作一般要求在200ms以內完成。
如果使用MQ，A系統連續傳送3條訊息到MQ佇列中，假如耗時5ms，A系統從接收一個請求到返回響應使用者總時長8ms
多應用對訊息佇列中同一訊息進行處理，應用併發處理訊息，相比序列處理，減少處理時間

削峰：每天0到12點，系統風平浪靜，每秒併發請求數量就50個，結果一到12:00~13:00,每秒併發請求數量突然會暴增到5k+條，但是系統直接基於mysql，大量請求湧入mysql，一般mysql，扛到每秒2k條就差不多，直接請求5k的話，導致系統崩潰。
如果使用MQ，每秒5k請求寫入MQ，系統每秒還是從MQ中拉取2k個請求，這樣哪怕是高峰期，系統也不會掛掉，但每秒5k進，2k出導致在高峰期可能有十幾萬甚至幾百萬的請求積壓在MQ中，短暫高峰期是OK的，高峰期一過依然處理積壓請求。

官方文件

https://www.cnblogs.com/linjiqin/p/5720865.html

同類產品

ActiveMQ RocketMQ Kafaka等

SpringCloud預設推薦使用RibbitMQ

安裝步驟 使用Docker搭建RabbitMQ

1）拉取映象：docker pull rabbitmq:management

2）檢視當前映象列表：docker images

3）刪除指定映象：docker rmi IMAGE_ID (如果需要強制刪除加 -f)

4）建立容器
docker run -d --name=“myrabbitmq” -p 5671:5671 -p 15672:15672 rabbitmq:management

引數講解：
run：建立一個新的容器並執行一個命令
-d：後臺執行容器，並返回容器ID
-p：埠對映，格式為：主機(宿主) 埠：容器埠
–name=“rabbitmq”：位容器指定一個名稱

RabbitMQ預設建立了一個guest使用者，密碼也是guest，如果訪問不了記得檢視防火牆，埠或者雲伺服器的安全管理後臺：http:/127.0.0.1:15672

可以參考部落格講解RibbitMQ控制檯