RabbitMQ的應(yīng)用場景以及基本原理介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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