志宇-RabbitMQ学习
RabbitMQ
- RabbitMQ安裝
- RabbitMQ使用
- RabbitMQ發送消息步驟圖
- 公平消費和消息可靠性傳遞
- 防止重復消費
- 有序消費
- 消息堆積怎么處理
- spring集成RabbitMQ使用
- RabbitMQ知識點
- SpringBoot集成RabbitMQ源碼學習
RabbitMQ安裝
推薦使用docker安裝,不然要安裝Erlang語言環境相對麻煩
1、拉取鏡像
docker pull rabbitmq:management
2、啟動RabbitMQ
docker run -d 以守護進程方式在后臺運行
--hostname rabbit_host1 設定容器的主機名(集群區分節點)
--name xd_rabbit 指定容器名
-e RABBITMQ_DEFAULT_USER=admin 用戶名
-e RABBITMQ_DEFAULT_PASS=admin 密碼
-p 15672:15672 控制臺界面管理的端口映射
-p 5672:5672 程序訪問的端口映射
rabbitmq:management
3、查看啟動日志
docker logs 返回的容器id
4、控制臺訪問(使用配置的用戶名和密碼)
http://www.lizhiyu.xyz:15672/
RabbitMQ使用
java依賴
簡單使用、不使用交換機、任務只會被一個消費者消費
RabbitMQ發送消息步驟圖
上圖說明如下 1、如上包括發送客戶端、RabbitMQ server、接收客戶端 2、RabbitMQ server中又包括 Virtual host(虛擬主機)、exchange(交換機)、queue(隊列) 3、虛擬主機 可以用于區分開發環境,發送端發送數據時要指定發送給哪個環境 4、隊列 用于存儲消息 5、交換機 交換機接收發送端發送的路由鍵(RoutingKey 最大長度255字節),根據接收的RoutingKey和配置的路由規則將發送的信息傳遞給指定隊列(起到路由的作用)使用說明如下 1、在RabbitMQ控制臺創建虛擬主機(一個虛擬主機下默認有7個exchange) 2、創建交換機交換機類型有5種 direct,fanout,topic,headers,systemfanout 代表廣播類型(也就是綁定的所有隊列都會接收信息、這樣RoutingKey就不用了因不需要路由到指定隊列)direct 代表直連類型(可以通過指定的RouterKey路由到指定的隊列)例如:RouterKey為aaa則路由到aaa對應的隊列topic 代表主題類型(可以通過一類的RouterKey進行路由到指定的隊列)符號“#”匹配一個或多個詞,符號“*”匹配不多不少一個詞例如:RouterKey為aaa.*.* 或 aaa.* 會路由到aaa.#對應的隊列RouterKey為aaa.* 會路由到aaa.*對應的隊列topic相對于direct和fanout更加靈活不使用交換機,不設置交換機這樣就是用了默認交換機(來達到消息只被消費一次) 3、創建隊列設定隊列中存儲內容持久化到本地(用于RabbitMQ崩潰后重啟隊列中已經存儲的數據不丟失)設定隊列最大長度設定隊列是否獨占ttl說明:time to live 消息存活時間設定隊列中信息的ttl(隊列中信息過了指定時長沒有被消費、就會處理這個消息)設置死信交換機(將隊列中的消息超過時長則將消息發送給死信交換機處理)當消費者拒收消息或隊列滿了或隊列中消息ttl達到極限則會將消息發送給信交換機 5、將交換機和隊列通過RoutingKey的規則進行綁定(目的:設定路由規則)也就是說下次發送端發送過來的RoutingKey會根據設定的規則發送到指定隊列 6、發送端設定用戶名、密碼、端口、虛擬主機、以及RouteringKey、交換機、將消息發送RabbitMQ廣播(Exchange的fanout類型使用)
RabbitMQ指定交換機給哪些隊列發送消息(Exchange的direct類型使用)
RabbitMQ根據消息類型將消息發送給指定隊列(Exchange的topic類型使用)
公平消費和消息可靠性傳遞
消息可靠性傳遞要確保使用如下方法
一、接收端使用消息確認機制(從而確認消費端是否消費此任務) 二、RabbitMQ隊列消息持久化到內存中(在RabbitMQ崩潰后重啟確保任務不丟失) 三、發送端發布確認機制(在RabbitMQ崩潰時,有可能有些正在發布的任務還沒有持久化,還在內存中從而導致消息丟失) 發布確認分為兩個階段1.發送端成功將消息發送給交換機(exchange),exchange成功接收消息2.交換機(exchange)根據routerKey將消息發送給指定隊列,隊列成功接收消息3.如果消息發送失敗,失敗后會觸發監聽然后重新發送消息(可以設置重新發送的次數)公平消費的方法
RabbitMQ沒有辦法感知接收端正在處理的任務數量,僅僅是平均分配,這達不到我們想要的公平消費,通過接收端沒有確認的消息數量來判斷正在處理的任務數來達到公平消費。防止重復消費
消息重復會重復的原因
1、在生產者將消息發送給交換機后,可能由于網絡原因生產者沒有收到交換機已經收到消息的回復,導致生產者將同一條消息再次發送給交換機 2、隊列中的消息交給消費者消費過程中,可能由于網絡原因隊列沒有收到消費者已經消費了此消息的回復,導致隊列中的消息再次被消費者消費防止重復消費
網絡問題無法解決需要消費者處接口處理保持冪等性 1、根據消息的唯一id,使用redis 自增,如果增加到1則不進行處理有序消費
有序消費 場景1:一個生產者對應一個消費者
有序消費 場景2:一個生產者對應多個消費者
消息堆積怎么處理
首先看功能是否需要暫停,找到錯誤原因 將舊的消息移動到一個緩存隊列中,首先不影響新的消息被消費 然后在慢慢消費緩存隊列中的信息spring集成RabbitMQ使用
springAMQP文檔
springAMQP詳細說明
自學代碼地址
RabbitMQ知識點
1、purge 清除(在清空隊列消息時候用到) 2、消息移動 3、手動確認和自動確認自動確認:可以配置重試次數,重試超過固定次數則拋棄或另外處理此消息手動確認:隊列將消息發送給消費者后,如果消費者不回復隊列會一直任務此消息消費者一直在執行(必須要給隊列一個回復是否執行成功,不然隊列會一直等著這條信息執行完,除非消費者掛掉了再分配此消息)手動確認如果沒有成功消費時:可以用reids中的標識來判斷是否要再次入隊 4、隊列排他獨占 5、通過死信隊列延時執行任務時候,隊列和死信交換機綁定的ttl等參數消費者重啟后不會覆蓋,需要重啟前刪除此隊列、或者沒有修改此隊隊列對應參數SpringBoot集成RabbitMQ源碼學習
參考
總結
以上是生活随笔為你收集整理的志宇-RabbitMQ学习的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 基于改进NSGA-Ⅱ算法的开关磁阻电机再
- 下一篇: 跟着CTF-Wiki学pwn|格式化字符