閱讀原文:https://blog.bywind.cn/articles/2018/11/28/1543373589258.html
視訊教程:https://www.bilibili.com/video/av35595465
課程原始碼:https://github.com/ibywind/springboot-learn
關注公眾號 檢視更多技術乾貨
還可加群 , 眾多好基友在等你

springboot 書籍 PDF 下載

掃描關注上方公眾號
回覆關鍵字 boot
就可以下載這本書了
書籍的排版很好的,我自己也在看.大家可以一起交流哦

寫在前面

hello 大家好

歡迎大家收看御風大世界

本次課是

springboot 系列教程第10課

我將為大家演示

springboot中如何整合訊息中介軟體

本節課視訊演示比圖文描述更清晰

如果要學習的朋友, 直接轉視訊哦

B站視訊更清晰

Mq的好處

介面 VS Mq

看到張圖了嗎？

中間多了個物件 （中介軟體）

我們 之間不再 需要 你依賴我 我依賴你了

而是 交給一個 中間人

各取所需啊。

以前 我要告訴你 我OK了 ， 然後 你 回覆 好的 我知道了

然後 我接收到 你說 你知道了

我才能 真的 OK了

而且 重試 的話 還需要 依賴定時任務 或者 快取狀態

現在 可靠投遞、廣播、流量控制、最終一致性

這些 都可以交給 Mq 了

好爽啊 ！！！

再給你來幾個 Mq 的優勢吧 （面試能用上）

1、 非同步通訊

有些業務不想也不需要立即處理訊息。訊息佇列提供了非同步處理機制，允許使用者把一個訊息放入佇列，但並不立即處理它。想向佇列中放入多少訊息就放多少，然後在需要的時候再去處理它們。

2、 解耦

降低工程間的強依賴程度，針對異構系統進行適配。在專案啟動之初來預測將來專案會碰到什麼需求，是極其困難的。通過訊息系統在處理過程中間插入了一個隱含的、基於資料的介面層，兩邊的處理過程都要實現這一介面，當應用發生變化時，可以獨立的擴充套件或修改兩邊的處理過程，只要確保它們遵守同樣的介面約束。

3、 冗餘

有些情況下，處理資料的過程會失敗。除非資料被持久化，否則將造成丟失。訊息佇列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丟失風險。許多訊息佇列所採用的”插入-獲取-刪除”正規化中，在把一個訊息從佇列中刪除之前，需要你的處理系統明確的指出該訊息已經被處理完畢，從而確保你的資料被安全的儲存直到你使用完畢。

4、擴充套件性

因為訊息佇列解耦了你的處理過程，所以增大訊息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變程式碼、不需要調節引數。便於分散式擴容。

5、過載保護

在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量無法提取預知；如果以為了能處理這類瞬間峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用訊息佇列能夠使關鍵元件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。

6、可恢復性

系統的一部分元件失效時，不會影響到整個系統。訊息佇列降低了程序間的耦合度，所以即使一個處理訊息的程序掛掉，加入佇列中的訊息仍然可以在系統恢復後被處理。

7、順序保證

在大多使用場景下，資料處理的順序都很重要。大部分訊息佇列本來就是排序的，並且能保證資料會按照特定的順序來處理。

8、緩衝

在任何重要的系統中，都會有需要不同的處理時間的元素。訊息佇列通過一個緩衝層來幫助任務最高效率的執行，該緩衝有助於控制和優化資料流經過系統的速度。以調節系統響應時間。

9、資料流處理

分散式系統產生的海量資料流，如：業務日誌、監控資料、使用者行為等，針對這些資料流進行實時或批量採集彙總，然後進行大資料分析是當前網際網路的必備技術，通過訊息佇列完成此類資料收集是最好的選擇。

RabbitMq為什麼牛逼？

AMQP協議

介紹RabbitMQ就必須先介紹AMQP協議，因為RabbitMQ是它的一種實現而已。

AMQP，即Advanced Message Queuing Protocol,一個提供統一訊息服務的應用層標準高階訊息佇列協議,是應用層協議的一個開放標準,為面向訊息的中介軟體設計。基於此協議的客戶端與訊息中介軟體可傳遞訊息，並不受客戶端/中介軟體不同產品，不同的開發語言等條件的限制。

AMQP模型

1.Server(broker): 接受客戶端連線，實現AMQP訊息佇列和路由功能的程序，可以理解為郵局。

2.Virtual Host:其實是一個虛擬概念，類似於許可權控制組，一個Virtual Host裡面可以有若干個Exchange和Queue，當多個不同的使用者使用同一個RabbitMQ server提供的服務時，可以劃分出多個vhost，每個使用者在自己的vhost建立exchange／queue等，就好比於tomcat中webapps目錄下可以部署多個web專案。

3.Exchange:接受生產者傳送的訊息，並根據Binding規則將訊息路由給伺服器中的佇列，就好比郵遞員。

4.Message Queue：訊息佇列，用於儲存還未被消費者消費的訊息，就好比於郵箱。

5.Message: 由Header和Body組成，Header是由生產者新增的各種屬性的集合，包括Message是否被持久化、由哪個Message Queue接受、優先順序是多少等，就好比於郵箱裡面的信件。而Body是真正需要傳輸的APP資料，就像信件裡面的信紙。

6.Binding:Binding聯絡了Exchange與Message Queue。Exchange在與多個Message Queue發生Binding後會生成一張路由表，路由表中儲存著Message Queue所需訊息的限制條件即Binding Key。當Exchange收到Message時會解析其Header得到Routing Key，Exchange根據Routing Key與Exchange Type將Message路由到Message Queue。Binding Key由Consumer在Binding Exchange與Message Queue時指定，而Routing Key由Producer傳送Message時指定，兩者的匹配方式由Exchange Type決定，就好比於郵件上面的地址。

7.Connection:連線，對於RabbitMQ而言，其實就是一個位於客戶端和Broker之間的TCP連線。

8.Channel:通道，僅僅建立了客戶端到Broker之間的連線後，客戶端還是不能傳送訊息的。需要為每一個Connection建立Channel，AMQP協議規定只有通過Channel才能執行AMQP的命令。一個Connection可以包含多個Channel。之所以需要Channel，是因為TCP連線的建立和釋放都是十分昂貴的，如果一個客戶端每一個執行緒都需要與Broker互動，如果每一個執行緒都建立一個TCP連線，暫且不考慮TCP連線是否浪費，就算作業系統也無法承受每秒建立如此多的TCP連線，可以簡單的理解為執行緒池中的一個個執行緒。

下圖是簡單的對比圖：

如果大家對於 各個主流Mq的 對比想要做深入研究

可以去這個地址看下

springboot整合RabbitMq

如果你像我一樣沒有 rabbitMq 環境的話

可以在這個網站下載

http://www.erlang.org/downloads

或者是 我為大家準備的百度雲盤

因為 rabbitmq 需要依賴 erlang 環境

所以你安裝完了以後 還需要 配置ERLANG_HOME環境變數

然後你就需要去下載RabbitMq了

下載地址

安裝完成以後 我們來到這個目錄

然後 我們安裝一個 管理介面外掛

命令如下 ：rabbitmq-plugins enable rabbitmq_management

然後你就可以訪問這個 介面了

初始使用者名稱、密碼 ：guest/guest

我們新建一個使用者 admin | 123456 用於我們程式演示程式碼

springboot 官方就已經支援了 RabbitMq

我們需要用上的話

要引入pom依賴

測試Mq 需要有 訊息產出 訊息消費

因此我們需要新建立兩個專案

mq-producer

mq-consumer

使用整合工具構建

總的一個結構是這樣的

在你新建多個 springboot專案的時候

IDEA會提示你 使用 spring dashboard

你點選確認顯示

這樣就比較好統一管理了

然後就是在 各自的 application.properties 中配置相關引數了

spring.application.name=mq-producer
spring.rabbitmq.host=127.0.0.1
spring.rabbitmq.port=5672
spring.rabbitmq.username=admin
spring.rabbitmq.password=123456

接著我們就開始寫我們的程式

這塊我建議大家看我的視訊

https://www.bilibili.com/video/av35595465/

給你截圖 看下執行結果吧

結束語

如果大家對於這裡比較感興趣的話

可以去B站檢視我的視訊講解

https://www.bilibili.com/video/av35595465/

或者是在 github下載原始碼

https://github.com/ibywind/springboot-learn