rabbitmq 限制速度_=(:) RabbitMQ详解
本篇包含了RabbitMQ概念的一些東西，下篇會整理出SpringBoot結合RabbitMQ的使用案例。
目錄
一、MQ概述
1.什么是消息
2.什么是消息隊列
3.MQ的特點
二、MQ適用場景
1.解耦
2.異步
3.削峰
4.使用MQ優缺點
三、MQ選型對比
1.Kafka
2.RabbitMQ
3.RocketMQ
4.選型和對比
四、RabbitMQ概述
1.概念
2.特點
3.概念模型
五、交換機類型
1.Direct Exchange
2.Fanout Exchange
3.Topic Exchange
4. Headers Exchanges
MQ概述
1.什么是消息
我們都知道RabbitMQ是一款消息隊列中間件，那如何理解消息呢？
消息(Message)是指在應用間傳遞的數據。
消息可以非常簡單，比如只包含文本字符串，也可以更復雜，比如包含對象和JSON數據。
2.什么是消息隊列
消息隊列(Message Queue)是一種應用間的通訊方式，也可以理解為是保存消息的的一個容器。消息發布者只管把消息發布到MQ而不用管誰來取，消息使用者只管從MQ中取消息而不用管是誰發布的。
3.MQ的特點
先進先出
不能先進先出，都不能說是隊列了。消息隊列的順序在入隊的時候就基本已經確定了，一般是不需人工干預的。而且，最重要的是，數據是只有一條數據在使用中。這也是MQ在諸多場景被使用的原因。
發布訂閱
發布訂閱是一種很高效的處理方式，如果不發生阻塞，基本可以當做是同步操作。這種處理方式能非常有效的提升服務器利用率，這樣的應用場景非常廣泛。
持久化
持久化確保MQ的使用不只是一個部分場景的輔助工具，而是讓MQ能像數據庫一樣存儲核心的數據。
分布式
在現在大流量、大數據的使用場景下，只支持單體應用的服務器軟件基本是無法使用的，支持分布式的部署，才能被廣泛使用。而且，MQ的定位就是一個高性能的中間件。
從以上描述可以看出消息隊列是一種應用間的異步協作機制，那什么時候需要使用MQ呢？
MQ適用場景
1.解耦
場景說明：用戶下單后，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的接口。
傳統模式：
?假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗。
訂單系統與庫存系統耦合。
引入消息隊列：
?訂單系統：用戶下單后，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。
?庫存系統：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作。
假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單后，訂單系統寫入消息隊列就不再關心其他的后續操作了。實現訂單系統與庫存系統的應用解耦。
為了保證庫存肯定有，可以將隊列大小設置成庫存數量，或者采用其他方式解決。
2.異步
場景說明：用戶注冊后，需要發注冊郵件和注冊短信。傳統的做法有兩種 1.串行的方式；2.并行方式
串行方式：將注冊信息寫入數據庫成功后，發送注冊郵件，再發送注冊短信。以上三個任務全部完成后，返回給客戶端。
并行方式：將注冊信息寫入數據庫成功后，發送注冊郵件的同時，發送注冊短信。以上三個任務完成后，返回給客戶端。與串行的差別是，并行的方式可以提高處理的時間。
引入消息隊列：將不是必須的業務邏輯，異步處理。
3.削峰
流量削峰也是消息隊列中的常用場景，一般在秒殺或搶購活動中使用廣泛。
應用場景：系統其他時間A系統每秒請求量就100個，系統可以穩定運行。系統每天晚間八點有秒殺活動，每秒并發請求量增至1萬條，但是系統最大的處理能力只能每秒處理1000個請求，于是系統崩潰，服務器宕機。
傳統架構：大量用戶(100萬用戶)通過瀏覽器在晚上八點高峰期同時參與秒殺活動。大量的請求涌入我們的系統中，高峰期達到每秒鐘5000個請求，大量的請求打到MySQL上，每秒鐘預計執行3000條SQL。但是一般的MySQL每秒鐘扛住2000個請求就不錯了，如果達到3000個請求的話可能MySQL直接就癱瘓了，從而系統無法被使用。
但是高峰期過了之后，就成了低峰期，可能也就1萬用戶訪問系統，每秒的請求數量也就50個左右，整個系統幾乎沒有任何壓力。
引入MQ：100萬用戶在高峰期的時候，每秒請求有5000個請求左右，將這5000請求寫入MQ里面，系統A每秒最多只能處理2000請求，因為MySQL每秒只能處理2000個請求。系統A從MQ中慢慢拉取請求，每秒就拉取2000個請求，不要超過自己每秒能處理的請求數量即可。MQ，每秒5000個請求進來，結果只有2000個請求出去，所以在秒殺期間(將近一小時)可能會有幾十萬或者幾百萬的請求積壓在MQ中。這個短暫的高峰期積壓是沒問題的，因為高峰期過了之后，每秒就只有50個請求進入MQ了，但是系統還是按照每秒2000個請求的速度在處理，所以說，只要高峰期一過，系統就會快速將積壓的消息消費掉。我們在此計算一下，每秒在MQ積壓3000條消息，1分鐘會積壓18萬，1小時積壓1000萬條消息，高峰期過后，1個多小時就可以將積壓的1000萬消息消費掉。
4.使用MQ優缺點
優點
優點就是以上的那些場景應用，就是在特殊場景下有其對應的好處，解耦、異步、削峰。
缺點
系統的可用性降低：系統引入的外部依賴越多，系統越容易掛掉，本來只是A系統調用BCD三個系統接口就好，ABCD四個系統不報錯整個系統會正常運行。引入了MQ之后，雖然ABCD系統沒出錯，但MQ掛了以后，整個系統也會崩潰。
系統的復雜性提高：引入了MQ之后，需要考慮的問題也變得多了，如何保證消息沒有重復消費？如何保證消息不丟失？怎么保證消息傳遞的順序？
一致性問題：A系統發送完消息直接返回成功，但是BCD系統之中若有系統寫庫失敗，則會產生數據不一致的問題。
那么，消息中間件性能究竟哪家強?
MQ選型對比
1.Kafka
Kafka是LinkedIn開源的分布式發布-訂閱消息系統，目前歸屬于Apache頂級項目。Kafka主要特點是基于Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用于日志收集和傳輸。0.8版本開始支持復制，不支持事務，對消息的重復、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。
2.RabbitMQ
RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基于AMQP協議來實現。AMQP的主要特征是面向消息、隊列、路由(包括點對點和發布/訂閱)、可靠性、安全。AMQP協議更多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。
3.RocketMQ
RocketMQ是阿里開源的消息中間件，它是純Java開發，具有高吞吐量、高可用性、適合大規模分布式系統應用的特點。RocketMQ思路起源于Kafka，但并不是Kafka的一個Copy，它對消息的可靠傳輸及事務性做了優化，目前在阿里集團被廣泛應用于交易、充值、流計算、消息推送、日志流式處理、binglog分發等場景。
4.選型和對比
從社區活躍度
按照目前網絡上的資料，RabbitMQ 、ActiveMQ、ZeroMQ 三者中，綜合來看，RabbitMQ 是首選。
持久化消息比較
ZeroMQ 不支持，ActiveMQ 和RabbitMQ 都支持。持久化消息主要是指我們機器在不可抗力因素等情況下掛掉了，消息不會丟失的機制。
綜合技術實現
可靠性、靈活的路由、集群、事務、高可用的隊列、消息排序、問題追蹤、可視化管理工具、插件系? 統等等。
RabbitMQ / Kafka 最好，ActiveMQ 次之，ZeroMQ 最差。當然ZeroMQ 也可以做到，不過自己必須手 動寫代碼實現，代碼量不小。尤其是可靠性中的：持久性、投遞確認、發布者證實和高可用性。
高并發
毋庸置疑，RabbitMQ 最高，原因是它的實現語言是天生具備高并發高可用的erlang 語言。
定位
Kafka 的定位主要在日志等方面， 因為Kafka 設計的初衷就是處理日志的，可以看做是一個日志(消息)系統一個重要組件，針對性很強，所以 如果業務方面還是建議選擇 RabbitMQ 。
選型最后總結
如果我們系統中已經有選擇? Kafka ?，或者? ?RabbitMQ ?，并且完全可以滿足現在的業務，建議就不用重復去增加和造輪子。
可以在? Kafka ?和? ?RabbitMQ ?中選擇一個適合自己團隊和業務的，這個才是最重要的。但是毋庸置疑現階段，綜合考慮沒有第三選擇。
參考
Kafka、RabbitMQ、RocketMQ等消息中間件的介紹和對比?
https://blog.csdn.net/yunfeng482/article/details/72856762
RabbitMQ概述
1.概念
RabbitMQ是一個由Erlang語言開發的AMQP的開源實現。
RabbitMQ最初起源于金融系統，用于在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
移步官網>>>(https://www.rabbitmq.com/)
AMQP：Advanced Message Queue，高級消息隊列協議，它是應用層協議的一個開放標準，為面向消息的中間件設計，基于此協議的客戶端與消息中間件可傳遞消息，并不受產品、開發語言等條件的限制。
Erlang是一種面向并發的通用編程語言，它由瑞典電信設備制造商愛立信所轄的計算機科學研究室開發，目的是創造一種可以應付大規模并發行為的編程語言和執行環境。
2.特點
可靠性(Reliability)
RabbitMQ 使用一些機制來保證可靠性，如持久化、傳輸確認、發布確認。
靈活的路由(Flexible Routing)
在消息進入隊列之前，通過 Exchange 來路由消息的。對于典型的路由功能，RabbitMQ 已經提供了一些內置的 Exchange 來實現。針對更復雜的路由功能，可以將多個 Exchange 綁定在一起，也通過插件機制實現自己的 Exchange 。
消息集群(Clustering)
多個 RabbitMQ 服務器可以組成一個集群，形成一個邏輯 Broker 。
高可用(Highly Available Queues)
隊列可以在集群中的機器上進行鏡像，使得在部分節點出問題的情況下隊列仍然可用。
多種協議(Multi-protocol)
RabbitMQ 支持多種消息隊列協議，比如 STOMP、MQTT 等等。
多語言客戶端(Many Clients)
RabbitMQ 幾乎支持所有常用語言，比如 Java、.NET、Ruby 等等。
管理界面(Management UI)
RabbitMQ 提供了一個易用的用戶界面，使得用戶可以監控和管理消息 Broker 的許多方面。
跟蹤機制(Tracing)
如果消息異常，RabbitMQ 提供了消息跟蹤機制，使用者可以找出發生了什么。
插件機制(Plugin System)
RabbitMQ 提供了許多插件，來從多方面進行擴展，也可以編寫自己的插件。
3.概念模型
Message
消息，消息是不具名的，它由消息頭和消息體組成。消息體是不透明的，而消息頭則由一系列的可選屬性組成，這些屬性包括routing-key(路由鍵)、priority(相對于其他消息的優先權)、delivery-mode(指出該消息可能需要持久性存儲)等。
Publisher
消息的生產者，也是一個向交換器發布消息的客戶端應用程序。
Exchange
交換器，用來接收生產者發送的消息并將這些消息路由給服務器中的隊列。
Binding
綁定，用于消息隊列和交換器之間的關聯。一個綁定就是基于路由鍵將交換器和消息隊列連接起來的路由規則，所以可以將交換器理解成一個由綁定構成的路由表。
Queue
消息隊列，用來保存消息直到發送給消費者。它是消息的容器，也是消息的終點。一個消息可投入一個或多個隊列。消息一直在隊列里面，等待消費者連接到這個隊列將其取走。
?Connection
網絡連接，比如一個TCP連接。
Channel
信道，多路復用連接中的一條獨立的雙向數據流通道。信道是建立在真實的TCP連接內的虛擬連接，AMQP 命令都是通過信道發出去的，不管是發布消息、訂閱隊列還是接收消息，這些動作都是通過信道完成。因為對于操作系統來說建立和銷毀 TCP 都是非常昂貴的開銷，所以引入了信道的概念，以復用一條 TCP 連接。
Consumer
消息的消費者，表示一個從消息隊列中取得消息的客戶端應用程序。
Virtual Host
虛擬主機，表示一批交換器、消息隊列和相關對象。虛擬主機是共享相同的身份認證和加密環境的獨立服務器域。每個 vhost 本質上就是一個 mini 版的 RabbitMQ 服務器，擁有自己的隊列、交換器、綁定和權限機制。vhost 是 AMQP 概念的基礎，必須在連接時指定，RabbitMQ 默認的 vhost 是 / 。
Broker
表示MQ服務器實體。
交換機類型
1.Direct Exchange
直連交換機，需要將一個隊列綁定到交換機上，要求該消息與一個特定的路由鍵完全匹配。這是一個完整的匹配。如果一個隊列綁定到該交換機上要求路由鍵“abc”，則只有被標記為“abc”的消息才被轉發，不會轉發abc.def，也不會轉發dog.ghi，只會轉發abc。
2.Fanout Exchange
廣播交換機，將消息路由給綁定到它身上的所有隊列，與綁定的路由鍵無關。
如果N個隊列綁定到某個扇型交換機上，當有消息發送給此扇型交換機時，交換機會將消息的拷貝分別發送給這所有的N個隊列。扇型用來交換機處理消息的廣播路由(broadcast routing)。所以扇形交換機主要做的就是廣播消息。
應用場景：
?大規模多用戶在線(MMO)游戲可以使用它來處理排行榜更新等全局事件。
體育新聞網站可以用它來近乎實時地將比分更新分發給移動客戶端。
分發系統使用它來廣播各種狀態和配置更新。
在群聊的時候，它被用來分發消息給參與群聊的用戶。(AMQP沒有內置presence的概念，因此XMPP可能會是個更好的選擇)
3.Topic Exchange
主題交換機，將路由鍵和某模式進行匹配。此時隊列需要綁定要一個模式上。符號“#”匹配一個或多個詞，符號“”匹配不多不少一個詞。因此“abc.#”能夠匹配到“abc.def.ghi”，但是“abc.” 只會匹配到“abc.def”。
4. Headers Exchanges
頭交換機，有時消息的路由操作會涉及到多個屬性，此時使用消息頭就比用路由鍵更容易表達，頭交換機(headers ?exchange)就是為此而生的。
頭交換機使用多個消息屬性來代替路由鍵建立路由規則。通過判斷消息頭的值能否與指定的綁定相匹配來確立路由規則。
我們可以綁定一個隊列到頭交換機上，并給他們之間的綁定使用多個用于匹配的頭(header)。
在頭交換機中需要考慮的是需要部分匹配還是全部匹配。相比較于直達交換機，頭交換機的優勢是匹配的規則不被限定為字符串，頭交換機需要在隊列綁定的規則中指定消息頭和匹配的規則。
匹配規則x-match有下列兩種類型：
x-match = all ：表示所有的鍵值對都匹配才能接受到消息
x-match = any ：表示只要有鍵值對匹配就能接受到消息
就是在指定消息頭(鍵值對)時，添加”x-match”參數，當”x-match”設置為“any”時，消息頭的任意一個值被匹配就可以滿足條件，而當”x-match”設置為“all”的時候，就需要消息頭的所有值都匹配成功。
頭交換機可以視為直連交換機的另一種表現形式。頭交換機能夠像直連交換機一樣工作，不同之處在于頭交換機的路由規則是建立在頭屬性值之上，而不是路由鍵。路由鍵必須是一個字符串，而頭屬性值則沒有這個約束，它們甚至可以是整數或者哈希值(字典)等。
生產者發送一個含有消息頭為 {“key2”：“value2”} 的消息，到頭交換機后，交換機會根據隊列綁定消息頭中“x-match”的匹配規則(就是上面介紹的all、any的規則)，把消息投遞給滿足消息頭匹配規則的隊列中，然后再投遞給監聽該隊列的用戶。
這里的匹配就是消息頭(鍵值對)模式，這個模式就是頭交換機。
參考
Hai Xiang
https://www.cnblogs.com/haixiang/p/10199754.html
Anumbrella??
https://blog.csdn.net/Anumbrella/article/details/80172515
預流
https://www.jianshu.com/p/79ca08116d57/
BraveSoul360
https://blog.csdn.net/yunfeng482/article/details/72856762
架構師梵心
https://www.cnblogs.com/fancyn/p/12560793.html
總結
以上是生活随笔為你收集整理的rabbitmq 限制速度_=(:) RabbitMQ详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 上海欢乐谷怎么没有夜场了
- 下一篇： python生成试卷制卷系统_Pytho