1、RabbitMQ的基本概念
RabbitMQ是一種消息中間件亦渗,用于處理來自客戶端的異步消息挖诸。服務(wù)端將要發(fā)送的消息放入到隊列池中。接收端可以根據(jù)RabbitMQ配置的轉(zhuǎn)發(fā)機(jī)制接收服務(wù)端發(fā)來的消息法精。RabbitMQ依據(jù)指定的轉(zhuǎn)發(fā)規(guī)則進(jìn)行消息的轉(zhuǎn)發(fā)多律、緩沖和持久化操作,主要用在多服務(wù)器間或單服務(wù)器的子系統(tǒng)間進(jìn)行通信亿虽,是分布式系統(tǒng)標(biāo)準(zhǔn)的配置菱涤。
Exchange
接受生產(chǎn)者發(fā)送的消息,并根據(jù)Binding規(guī)則將消息路由給服務(wù)器中的隊列洛勉。ExchangeType決定了Exchange路由消息的行為粘秆。在RabbitMQ中,ExchangeType常用的有direct收毫、Fanout和Topic三種攻走。
Message Queue
消息隊列。我們發(fā)送給RabbitMQ的消息最后都會到達(dá)各種queue此再,并且存儲在其中(如果路由找不到相應(yīng)的queue則數(shù)據(jù)會丟失)昔搂,等待消費(fèi)者來取。
Binding Key
它表示的是Exchange與Message Queue是通過binding key進(jìn)行聯(lián)系的输拇,這個關(guān)系是固定摘符。
Routing Key
生產(chǎn)者在將消息發(fā)送給Exchange的時候,一般會指定一個routing key,來指定這個消息的路由規(guī)則逛裤。這個routing key需要與Exchange Type及binding key聯(lián)合使用才能生瘩绒,我們的生產(chǎn)者只需要通過指定routing key來決定消息流向哪里。
2带族、RabbitMQ 使用場景
服務(wù)解耦
假設(shè)有這樣一個場景, 服務(wù)A產(chǎn)生數(shù)據(jù), 而服務(wù)B,C,D需要這些數(shù)據(jù), 那么我們可以在A服務(wù)中直接調(diào)用B,C,D服務(wù),把數(shù)據(jù)傳遞到下游服務(wù)即可锁荔。
但是,隨著我們的應(yīng)用規(guī)模不斷擴(kuò)大,會有更多的服務(wù)需要A的數(shù)據(jù),如果有幾十甚至幾百個下游服務(wù),而且會不斷變更,再加上還要考慮下游服務(wù)出錯的情況,那么A服務(wù)中調(diào)用代碼的維護(hù)會極為困難。
這是由于服務(wù)之間耦合度過于緊密蝙砌。
再來考慮用RabbitMQ解耦的情況阳堕。
A服務(wù)只需要向消息服務(wù)器發(fā)送消息,而不用考慮誰需要這些數(shù)據(jù);下游服務(wù)如果需要數(shù)據(jù),自行從消息服務(wù)器訂閱消息,不再需要數(shù)據(jù)時則取消訂閱即可。
流量削峰
假設(shè)我們有一個應(yīng)用,平時訪問量是每秒300請求,我們用一臺服務(wù)器即可輕松應(yīng)對择克。
而在高峰期,訪問量瞬間翻了十倍,達(dá)到每秒3000次請求,那么單臺服務(wù)器肯定無法應(yīng)對,這時我們可以考慮增加到10臺服務(wù)器,來分散訪問壓力恬总。
但如果這種瞬時高峰的情況每天只出現(xiàn)一次,每次只有半小時,那么我們10臺服務(wù)器在多數(shù)時間都只分擔(dān)每秒幾十次請求,這樣就有點浪費(fèi)資源了。
這種情況,我們就可以使用RabbitMQ來進(jìn)行流量削峰,高峰情況下,瞬間出現(xiàn)的大量請求數(shù)據(jù),先發(fā)送到消息隊列服務(wù)器,排隊等待被處理,而我們的應(yīng)用,可以慢慢的從消息隊列接收請求數(shù)據(jù)進(jìn)行處理,這樣把數(shù)據(jù)處理時間拉長,以減輕瞬時壓力祠饺。
這是消息隊列服務(wù)器非常典型的應(yīng)用場景越驻。
異步調(diào)用
考慮定外賣支付成功的情況。
支付后要發(fā)送支付成功的通知,再尋找外賣小哥來進(jìn)行配送,而尋找外賣小哥的過程非常耗時,尤其是高峰期,可能要等待幾十秒甚至更長道偷。
這樣就造成整條調(diào)用鏈路響應(yīng)非常緩慢缀旁。
而如果我們引入RabbitMQ消息隊列,訂單數(shù)據(jù)可以發(fā)送到消息隊列服務(wù)器,那么調(diào)用鏈路也就可以到此結(jié)束,訂單系統(tǒng)則可以立即得到響應(yīng),整條鏈路的響應(yīng)時間只有200毫秒左右。
尋找外賣小哥的應(yīng)用可以以異步的方式從消息隊列接收訂單消息,再執(zhí)行耗時的尋找操作勺鸦。