RabbitMQ怎么應(yīng)用

這篇文章將為大家詳細(xì)講解有關(guān)RabbitMQ怎么應(yīng)用，小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

異步處理

場(chǎng)景：發(fā)送手機(jī)驗(yàn)證碼，郵件

傳統(tǒng)古老處理方式如下圖

這個(gè)流程，全部在主線程完成，注冊(cè)-》入庫(kù)-》發(fā)送郵件-》發(fā)送短信，由于都在主線程，所以要等待每一步完成才能繼續(xù)執(zhí)行。由于每一步的操作時(shí)間響應(yīng)時(shí)間不固定，所以主線程的請(qǐng)求耗時(shí)可能會(huì)非常長(zhǎng)，如果請(qǐng)求過(guò)多，會(huì)導(dǎo)致IIS站點(diǎn)巨慢，排隊(duì)請(qǐng)求，甚至宕機(jī)，嚴(yán)重影響用戶體驗(yàn)。

現(xiàn)在大多數(shù)的處理方式如下圖

這個(gè)流程是，主線程依舊處理耗時(shí)低的入庫(kù)操作，然后把需要處理的消息寫(xiě)進(jìn)消息隊(duì)列中，這個(gè)寫(xiě)入耗時(shí)可以忽略不計(jì)，非常快，然后，獨(dú)立的發(fā)郵件子系統(tǒng)，和獨(dú)立的發(fā)短信子系統(tǒng)，同時(shí)訂閱消息隊(duì)列，進(jìn)行單獨(dú)處理。處理好之后，向隊(duì)列發(fā)送ACK確認(rèn)，消息隊(duì)列整條數(shù)據(jù)刪除。這個(gè)流程也是現(xiàn)在各大公司都在用的方式，以SOA服務(wù)化各個(gè)系統(tǒng)，把耗時(shí)操作，單獨(dú)交給獨(dú)立的業(yè)務(wù)系統(tǒng)，通過(guò)消息隊(duì)列作為中間件，達(dá)到應(yīng)用解耦的目的，并且消耗的資源很低，單臺(tái)服務(wù)器能承受更大的并發(fā)請(qǐng)求。

應(yīng)用解耦

以電商的下訂單為例子，假設(shè)中間的流程為下單=》減庫(kù)存=》發(fā)貨

第一種方式，通過(guò)連續(xù)操作表，在單一系統(tǒng)中，通過(guò)主線程，連續(xù)操作。呵呵噠，這種做法，相信很多人剛?cè)腴T(mén)，甚至幾年經(jīng)驗(yàn)了，由于項(xiàng)目小，也在繼續(xù)使用吧。用戶量少，或者都是內(nèi)部人使用，必然沒(méi)問(wèn)題，因?yàn)椴粫?huì)在意出的問(wèn)題，這種做法，只要一個(gè)環(huán)節(jié)出問(wèn)題，請(qǐng)求直接報(bào)錯(cuò)，導(dǎo)致用戶懵逼，假設(shè)在執(zhí)行到減庫(kù)存操作報(bào)錯(cuò)了，整個(gè)流程沒(méi)有用事務(wù)回滾的話，還會(huì)造成數(shù)據(jù)不一致。

第二種方式，把這三個(gè)業(yè)務(wù)，拆成三個(gè)獨(dú)立系統(tǒng)，通過(guò)JSON方式相互調(diào)用請(qǐng)求。這個(gè)做法，其實(shí)已經(jīng)很不錯(cuò)了，起碼獨(dú)立出來(lái)，各自做各自的事情，一定程度上減小了整個(gè)系統(tǒng)的耦合性。但是問(wèn)題是，就算是通過(guò)API形式請(qǐng)求，發(fā)送請(qǐng)求的系統(tǒng)一般情況下會(huì)等待被請(qǐng)求方的響應(yīng)，如果響應(yīng)錯(cuò)了，整個(gè)程序還是會(huì)終止，前面的業(yè)務(wù)系統(tǒng)假如已經(jīng)做了入庫(kù)操作，就必須要混滾了。很麻煩。如果說(shuō)不等待被請(qǐng)求方響應(yīng)的話，如果出錯(cuò)，如果還要保證數(shù)據(jù)一致性，就要做更多的操作，去補(bǔ)全數(shù)據(jù)，比如，下單成功，減庫(kù)存失敗，發(fā)貨成功，這樣當(dāng)減庫(kù)存系統(tǒng)修復(fù)后，就要通過(guò)訂單數(shù)據(jù)，去補(bǔ)庫(kù)存表的對(duì)應(yīng)數(shù)據(jù)。先對(duì)麻煩，難處理。

第三種方式，

把消息隊(duì)列作為中間件，當(dāng)訂單系統(tǒng)下完單后，把數(shù)據(jù)消息寫(xiě)入消息隊(duì)列中，庫(kù)存系統(tǒng)和發(fā)貨系統(tǒng)同時(shí)訂閱這個(gè)消息隊(duì)列，思想上和純API系統(tǒng)調(diào)用類似，但是，消息隊(duì)列RabbitMq本身的強(qiáng)大功能，會(huì)幫我們做大量的出錯(cuò)善后處理，還是，假設(shè)下單成功，庫(kù)存失敗，發(fā)貨成功，當(dāng)我們修復(fù)庫(kù)存的時(shí)候，不需要任何管數(shù)據(jù)的不一致性，因?yàn)閹?kù)存隊(duì)列未被處理的消息，會(huì)直接發(fā)送到庫(kù)存系統(tǒng)，庫(kù)存系統(tǒng)會(huì)進(jìn)行處理。實(shí)現(xiàn)了應(yīng)用的大幅度解耦。

流量削峰

這個(gè)主要用在團(tuán)購(gòu)，秒殺活動(dòng)中

這個(gè)主要原理就是，控制隊(duì)列長(zhǎng)度，當(dāng)請(qǐng)求來(lái)了，往隊(duì)列里寫(xiě)入，超過(guò)隊(duì)列的長(zhǎng)度，就返回失敗，給用戶報(bào)一個(gè)可愛(ài)的錯(cuò)誤頁(yè)的等等。

日志處理

這個(gè)場(chǎng)景應(yīng)該都很熟悉，一個(gè)系統(tǒng)有大量的業(yè)務(wù)需要各種日志來(lái)保證后續(xù)的分析工作，而且實(shí)時(shí)性要求不高，用隊(duì)列處理再好不過(guò)了

消息通訊

現(xiàn)在上線的各大社交通訊項(xiàng)目中，實(shí)際上是沒(méi)有用消息隊(duì)列做即時(shí)通訊的，但是它確實(shí)可以用來(lái)做，有興趣的不妨去試試吧

這個(gè)是點(diǎn)對(duì)點(diǎn)通信，消費(fèi)者A和B同時(shí)訂閱消息隊(duì)列，又同時(shí)是制造者，就能實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)通信

群聊的做法，所有客戶端同時(shí)訂閱隊(duì)列，又同時(shí)是發(fā)送，制造者。

區(qū)別

上述大致的5種RabbitMq的應(yīng)用場(chǎng)景，下面來(lái)介紹幾個(gè)消息隊(duì)列的區(qū)別

ActiveMq:這個(gè)應(yīng)用于JAVA中間件較多

ZeroMq:這個(gè)是分發(fā)效率最高的隊(duì)列，是其他隊(duì)列的十倍以上，缺點(diǎn)是不能數(shù)據(jù)持久化。

kafka：這是一種高吞吐量的發(fā)布訂閱消息系統(tǒng)，當(dāng)每秒達(dá)到10W+的分發(fā)要求時(shí)，可以用這個(gè)嘗試，新浪微博就是用這個(gè)做分發(fā)。

RabbitMQ 上的一個(gè) queue 中存放的 message 是否有數(shù)量限制？

可以認(rèn)為是無(wú)限制，因?yàn)橄拗迫Q于機(jī)器的內(nèi)存，但是消息過(guò)多會(huì)導(dǎo)致處理效率的下降。

RabbitMQ 概念里的 channel、exchange 和 queue 這些東東是邏輯概念，還是對(duì)應(yīng)著進(jìn)程實(shí)體？這些東東分別起什么作用？

queue 具有自己的 erlang 進(jìn)程；exchange 內(nèi)部實(shí)現(xiàn)為保存 binding 關(guān)系的查找表；channel 是實(shí)際進(jìn)行路由工作的實(shí)體，即負(fù)責(zé)按照 routing_key 將 message 投遞給 queue 。由 AMQP 協(xié)議描述可知，channel 是真實(shí) TCP 連接之上的虛擬連接，所有 AMQP 命令都是通過(guò) channel 發(fā)送的，且每一個(gè) channel 有唯一的 ID。一個(gè) channel 只能被單獨(dú)一個(gè)操作系統(tǒng)線程使用，故投遞到特定 channel 上的 message 是有順序的。但一個(gè)操作系統(tǒng)線程上允許使用多個(gè) channel 。channel 號(hào)為 0 的 channel 用于處理所有對(duì)于當(dāng)前 connection 全局有效的幀，而 1-65535 號(hào) channel 用于處理和特定 channel 相關(guān)的幀。AMQP 協(xié)議給出的 channel 復(fù)用模型如下

其中每一個(gè) channel 運(yùn)行在一個(gè)獨(dú)立的線程上，多線程共享同一個(gè) socket。

關(guān)于“RabbitMQ怎么應(yīng)用”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。