RabbitMQ的應用場景以及基本原理介紹

1、RabbitMQ 的應用場景以及基本原理介紹1. 背景RabbitMQ 是一個由 erlang 開發(fā)的 AMQP(AdvanvedMessage Queue) 的開源實現。2. 應用場景2.1 異步處理場景說明： 用戶注冊后， 需要發(fā)注冊郵件和注冊短信 ,傳統(tǒng)的 做法有兩種 1. 串行的方式 ;2.并行的方式(1) 串行方式 :將注冊信息寫入數據庫后 ,發(fā)送注冊郵件 ,再發(fā) 送注冊短信 , 以上三個任務全部完成后才返回給客戶端。這有一個問題是 ,郵件 ,短信并不是必須的 ,它只是一個通知 ,而 這種做法讓客戶端等待沒有必要等待的東西 .(2) 并行方式 :將注冊信息寫入數據庫后 ,發(fā)送郵件的同

2、時 ,發(fā) 送短信 , 以上三個任務完成后 ,返回給客戶端 ,并行的方式能提 高處理的時間。假設三個業(yè)務節(jié)點分別使用 50ms, 串行方式使用時間 150ms, 并行使用時間 100ms 。雖然并性已經提高的處理時 間,但是 ,前面說過 ,郵件和短信對我正常的使用網站沒有任何 影響，客戶端沒有必要等著其發(fā)送完成才顯示注冊成功,英愛是寫入數據庫后就返回 .(3) 消息隊列引入消息隊列后， 把發(fā)送郵件 ,短信不是必須的業(yè)務邏輯異步 處理由此可以看出 ,引入消息隊列后， 用戶的響應時間就等于寫入 數據庫的時間 +寫入消息隊列的時間 (可以忽略不計 ),引入消 息隊列后處理后 ,響應時間是串行的 3 倍

3、 ,是并行的 2 倍。 2.2 應用解耦場景：雙 11 是購物狂節(jié) ,用戶下單后 ,訂單系統(tǒng)需要通知庫存系統(tǒng),傳統(tǒng)的做法就是訂單系統(tǒng)調用庫存系統(tǒng)的接口這種做法有一個缺點 :當庫存系統(tǒng)出現故障時,訂單就會失敗。 （這樣馬云將少賺好多好多錢八八）訂單系統(tǒng)和庫存系統(tǒng)高耦合引入消息隊列訂單系統(tǒng) :用戶下單后 ,訂單系統(tǒng)完成持久化處理 ,將消息寫入 消息隊列 ,返回用戶訂單下單成功。庫存系統(tǒng):訂閱下單的消息,獲取下單消息 ,進行庫操作。就算庫存系統(tǒng)出現故障,消息隊列也能保證消息的可靠投遞不會導致消息丟失 （馬云這下高興了 ）.流量削峰流量削峰一般在秒殺活動中應用廣泛場景 :秒殺活動，一般會因為流量過大，

4、導致應用掛掉,為了解決這個問題，一般在應用前端加入消息隊列。作用:1. 可以控制活動人數， 超過此一定閥值的訂單直接丟棄（我為2. 可以緩解短時間的高流量壓垮應用 （應用程序按自己的最 大處理能力獲取訂單 ）1. 用戶的請求 ,服務器收到之后 ,首先寫入消息隊列 ,加入消息 隊列長度超過最大值 ,則直接拋棄用戶請求或跳轉到錯誤頁 面.2. 秒殺業(yè)務根據消息隊列中的請求信息，再做后續(xù)處理 .3. 系統(tǒng)架構幾個概念說明 :Broker: 它提供一種傳輸服務 ,它的角色就是維護一條從生產 者到消費者的路線，保證數據能按照指定的方式進行傳輸 ,Exchange ：消息交換機 ,它指定消息按什么規(guī)則 ,

5、路由到哪個 隊列。Queue: 消息的載體 ,每個消息都會被投到一個或多個隊列。Binding: 綁定，它的作用就是把 exchange 和 queue 按照路 由規(guī)則綁定起來 .Routing Key: 路由關鍵字 ,exchange 根據這個關鍵字進行消 息投遞。vhost: 虛擬主機 ,一個 broker 里可以有多個 vhost ，用作不同 用戶的權限分離。Producer: 消息生產者 ,就是投遞消息的程序 .Consumer: 消息消費者 ,就是接受消息的程序 .Channel: 消息通道 ,在客戶端的每個連接里 ,可建立多個 channel.4. 任務分發(fā)機制4.1Round-r

6、obin dispathching 循環(huán)分發(fā)RabbbitMQ 的分發(fā)機制非常適合擴展 ,而且它是專門為并發(fā) 程序設計的 ,如果現在 load 加重 ,那么只需要創(chuàng)建更多的Consumer 來進行任務處理。4.2Message acknowledgment 消息確認 為了保證數據不被丟失 ,RabbitMQ 支持消息確認機制 ,為了 保證數據能被正確處理而不僅僅是被 Consumer 收到 ,那么 我們不能采用 no-ack ，而應該是在處理完數據之后發(fā)送 ack.在處理完數據之后發(fā)送 ack, 就是告訴 RabbitMQ 數據已經被 接收 ,處理完成 ,RabbitMQ 可以安全的刪除它了

7、.如果 Consumer 退出了但是沒有發(fā)送 ack, 那么 RabbitMQ 就 會把這個 Message 發(fā)送到下一個 Consumer ，這樣就保證在 Consumer 異常退出情況下數據也不會丟失 .RabbitMQ 它沒有用到超時機制 .RabbitMQ 僅僅通過 Consumer 的連接中斷來確認該 Message 并沒有正確處理， 也就是說 RabbitMQ 給了 Consumer 足夠長的時間做數據處 理。如果忘記 ack, 那么當 Consumer 退出時 ,Mesage 會重新分發(fā) 然后 RabbitMQ 會占用越來越多的內存 .5. Message durability

8、消息持久化 要持久化隊列 queue 的持久化需要在聲明時指定durable=True;這里要注意 ,隊列的名字一定要是 Broker 中不存在的 ,不然不 能改變此隊列的任何屬性 .隊列和交換機有一個創(chuàng)建時候指定的標志 durable,durable 的唯一含義就是具有這個標志的隊列和交換機會在重啟之 后重新建立 , 它不表示說在隊列中的消息會在重啟后恢復消息持久化包括 3 部分1. exchange 持久化 , 在聲明時指定 durable = true hannel.ExchangeDeclare(ExchangeName, direct, durable: true, autoDele

9、te: false, arguments: null);/聲明消息隊列，且為可持久化的 12.queue 持久化 , 在聲明時指定 durable = true channel.QueueDeclare(QueueName, durable: true, exclusive: false, autoDelete: false, arguments: null);/聲明消息隊列，且為可持久化的 13. 消息持久化 ,在投遞時指定 delivery_mode = 2(1 是非持久 化).channel.basicPublish(, queueName,MessageProperties.PERSI

10、STENT_TEXT_PLAIN, msg.getBytes(); 1如果 exchange 和 queue 都是持久化的 , 那么它們之間的 binding 也是持久化的 ,如果 exchange 和 queue 兩者之間有 一個持久化，一個非持久化 , 則不允許建立綁定 .注意：一旦創(chuàng)建了隊列和交換機 ,就不能修改其標志了 ,例如 , 創(chuàng)建了一個 non-durable 的隊列 , 然后想把它改變成 durable 的,唯一的辦法就是刪除這個隊列然后重現創(chuàng)建。6. Fair dispath 公平分發(fā) 你可能也注意到了 , 分發(fā)機制不是那么優(yōu)雅 , 默認狀態(tài) 下 ,RabbitMQ 將第 n

11、 個 Message 分發(fā)給第 n 個 Consumer 。 n 是取余后的 , 它不管 Consumer 是否還有 unacked Message ，只是按照這個默認的機制進行分發(fā) .那么如果有個 Consumer 工作比較重 , 那么就會導致有的 Consumer 基本沒事可做 , 有的 Consumer 卻毫無休息的機會 那么 ,Rabbit 是如何處理這種問題呢 ?通過 basic.qos 方法設置 prefetch_count=1 ，這樣 RabbitMQ 就會使得每個 Consumer 在同一個時間點最多處理一個 Message ，換句話說 ,在接收到該 Consumer 的 ac

12、k 前 ,它不 會將新的 Message 分發(fā)給它 channel.basic_qos(prefetch_count=1) 1 注意，這種方法可能會導致 queue 滿。當然，這種情況下你 可能需要添加更多的 Consumer ，或者創(chuàng)建更多的 virtualHost 來細化你的設計。7. 分發(fā)到多個 Consumer7.1Exchange 先來溫習以下交換機路由的幾種類型 :Direct Exchange: 直接匹配 ,通過 Exchange 名稱 +RountingKey 來發(fā)送與接收消息 .Fanout Exchange: 廣播訂閱 , 向所有的消費者發(fā)布消息 , 但是 只有消費者將隊列

13、綁定到該路由器才能收到消息,忽略Routing Key.Topic Exchange ：主題匹配訂閱 , 這里的主題指的是 RoutingKey,RoutingKey 可以采用通配符 ,如 :*或 #， RoutingKey 命名采用 .來分隔多個詞 ,只有消息這將隊列綁定 到該路由器且指定 RoutingKey 符合匹配規(guī)則時才能收到消Headers Exchange: 消息頭訂閱 ,消息發(fā)布前 ,為消息定義一 個或多個鍵值對的消息頭 ,然后消費者接收消息同時需要定 義類似的鍵值對請求頭 :(如 :x-mactch=all 或者 x_match=any) ，只有請求頭與消息頭匹配, 才能接收

14、消息 , 忽略 RoutingKey.默認的 exchange: 如果用空字符串去聲明一個 exchange ，那 么系統(tǒng)就會使用”amq.direct ”這個hange，我們創(chuàng)建一個queue 時,默認的都會有一個和新建 queue 同名的 routingKey 綁定到這個默認的 exchange 上去 channel.BasicPublish(, TaskQueue, properties, bytes);1因為在第一個參數選擇了默認的 exchange ，而我們申明的 隊列叫 TaskQueue ，所以默認的，它在新建一個也叫 TaskQueue 的 routingKey ，并綁定在默認

15、的 exchange 上， 導致了我們可以在第二個參數 routingKey 中寫 TaskQueue ， 這樣它就會找到定義的同名的 queue ，并把消息放進去。如果有兩個接收程序都是用了同一個的 queue 和相同的 routingKey 去綁定 direct exchange 的話，分發(fā)的行為是負載均衡的，也就是說第一個是程序 1 收到，第二個是程序 2 收到，以此類推。如果有兩個接收程序用了各自的 queue ，但使用相同的 routingKey 去綁定 direct exchange 的話，分發(fā)的行為是復 制的，也就是說每個程序都會收到這個消息的副本。行為相 當于 fanout 類

16、型的 exchange 。下面詳細來說 :7.2 Bindings 綁定 綁定其實就是關聯了 exchange 和 queue ，或者這么 說 :queue 對 exchange 的內容感興趣 ,exchange 要把它的 Message deliver 到 queue 。7.3Direct exchangeDriect exchange 的路由算法非常簡單 :通過 bindingkey 的完 全匹配，可以用下圖來說明 .Exchange 和兩個隊列綁定在一起 ,Q1 的 bindingkey 是 orange ， Q2 的 binding key 是 black 和 green.當 Prod

17、ucer publish key 是 orange 時 ,exchange 會把它放到 Q1 上 ,如果是 black 或 green 就會到 Q2 上,其余的 Message 被丟棄 .7.4 Multiple bindings多個 queue 綁定同一個 key 也是可以的 , 對于下圖的例子 ,Q1 和 Q2 都綁定了 black, 對于 routing key 是 black 的 Message ， 會被 deliver 到 Q1 和 Q2 ，其余的 Message 都會被丟棄 . 7.5 Topic exchange對于 Message 的 routing_key 是有限制的，不能使

18、任意的。 格式是以點號“ . ”分割的字符表。比如：” “ nyse.vmw ” ,“ ”。你可以放任y意的routing_key 中，當然最長不能超過 255 bytes 。對于 routing_key ，有兩個特殊字符*（星號）代表任意一個單詞 #（hash）0 個或多個單詞Producer 發(fā)送消息時需要設置 routing_key ，routing_key 包含三個單詞和連個點號o,第一個key描述了 celerity（靈巧）,第二個是 color（ 色彩）,第三個是物種 :在這里我們創(chuàng)建了兩個綁定： Q1 的 binding key是” .orange. “Q；2 是“.rabbit 和”“ lazy.# ”：Q1 感興趣所有 orange 顏色的動物 Q2 感興趣所有 rabbits 和所有的 lazy 的.例子：rounting_key 為 “”