我們已經(jīng)成功的安裝了RabbitMQ,我們?yōu)槭裁匆褂肦abbitMQ,解決了什么問題,我們?cè)诎惭b的時(shí)候,我們一般在我們的系統(tǒng)當(dāng)中呢,通過RabbitMQ,或者消息中間件,不見得你非得用RabbitMQ,我們解決同步變異步的問題,那咱們先看什么是同步,我們那這個(gè)用例圖來看,比如一個(gè)用戶在使用我們的電商平臺(tái)的時(shí)候,他去購買了一個(gè)商品,并且下訂單了,這個(gè)時(shí)候肯定要向我們的訂單服務(wù)發(fā)送請(qǐng)求,比如這個(gè)時(shí)候他用時(shí)是50毫秒,然后訂單服務(wù)接收到請(qǐng)求以后呢,他還要去做其他服務(wù)的調(diào)用,比如我們要給用戶發(fā)短信,這個(gè)時(shí)候在我們的訂單服務(wù)當(dāng)中,要去調(diào)用短信服務(wù)的接口,比如這個(gè)時(shí)候用時(shí)比如50毫秒,然后等短信發(fā)完了,訂單服務(wù)再往下走,再去調(diào)用Email服務(wù),用戶發(fā)送Email,表示訂單創(chuàng)建成功,比如這個(gè)時(shí)候也是用時(shí)50毫秒,然后訂單服務(wù)去給App-push去發(fā)送請(qǐng)求,然后像我們的頁面也好,向其他的設(shè)備也好,比如這個(gè)時(shí)候又用時(shí)50毫秒,然后這一塊都完事了,最后返回給用戶,告訴他訂單創(chuàng)建成功,那么也就意味著,用戶下一個(gè)訂單,其實(shí)它總共耗時(shí)時(shí)間是200毫秒,因?yàn)槲覀兿掠唵我院?所有這些服務(wù)的調(diào)用,都是同步的,當(dāng)這個(gè)服務(wù)處理完之后,再轉(zhuǎn)向下一個(gè)服務(wù),等這些服務(wù)都處理完畢了,就會(huì)產(chǎn)生一個(gè)響應(yīng),并把訂單號(hào)發(fā)送給用戶,所以這個(gè)時(shí)候你會(huì)發(fā)現(xiàn),用戶下訂單的時(shí)間,是比較長(zhǎng)的,根據(jù)我們現(xiàn)在這個(gè)模型來看,他耗時(shí)200毫秒,并且服務(wù)和服務(wù)之間是強(qiáng)耦合,因?yàn)樵谟唵畏?wù)里去調(diào)的短信平臺(tái),調(diào)的Email服務(wù)平臺(tái)的接口,所有的接口都在訂單服務(wù)當(dāng)中,所以訂單服務(wù)和其他服務(wù)是緊耦合的,這是我們同步的一個(gè)現(xiàn)象,那么實(shí)際的電商平臺(tái)是這么設(shè)計(jì)的嗎,肯定不是,那我們?cè)趺醋龅哪?我們要把同步的現(xiàn)象,給他改變成異步處理,怎么做異步處理呢,第一種方式,我們可以加線程池,當(dāng)用戶去購買商品的時(shí)候,創(chuàng)建訂單,這個(gè)時(shí)候調(diào)用訂單服務(wù),然后訂單服務(wù)當(dāng)中呢,去線程池當(dāng)中去啟動(dòng)線程,我們都知道,線程它是啟動(dòng)完之后,是不會(huì)等待其他線程執(zhí)行完畢的,所以這是一個(gè)異步的,在線程池當(dāng)中,啟動(dòng)不同的線程操作或者調(diào)用不同平臺(tái)的接口,這樣也能將同步變成異步,就可以將同步轉(zhuǎn)換為異步,那么這么做有一個(gè)什么缺點(diǎn)呢,就是自己實(shí)現(xiàn)線程池,這個(gè)線程池就需要我們自己去編寫,并且他也是一個(gè)強(qiáng)耦合,因?yàn)榫€程池的代碼,訂單服務(wù)還是和這些服務(wù)是緊耦合的現(xiàn)象,所以這種方式雖然可以解決創(chuàng)建訂單時(shí),與其他服務(wù)接口同步的問題,通過線程來變成異步,但是還沒有解決他們之間的耦合度的問題

就是借助于我們的消息隊(duì)列,這是什么意思呢,我們要在我們的訂單系統(tǒng)以外,再加一個(gè)MQ的系統(tǒng),這個(gè)時(shí)候用戶在訂單的時(shí)候,還是訂單服務(wù),訂單服務(wù)像MQ系統(tǒng)發(fā)請(qǐng)求,然后就不管了,直接返回給用戶,拿到一個(gè)訂單ID返回給他就可以了,至于MQ系統(tǒng)做什么,去調(diào)用各個(gè)服務(wù)的接口,發(fā)送信息,告訴他你在發(fā)短信了,這個(gè)時(shí)候MQ再去和其他系統(tǒng)做通信的時(shí)候,跟我們的訂單服務(wù)已經(jīng)沒有關(guān)系了,因?yàn)樗峭耆?dú)立出來的一個(gè)系統(tǒng),我們就直接給客戶端,返回一個(gè)響應(yīng)就可以了,這樣就可以大大降低用戶創(chuàng)建所耗費(fèi)的一個(gè)時(shí)間,同時(shí)還完成了跟其他服務(wù)的一個(gè)耦合度,所以我們一般在開發(fā)的過程當(dāng)中,對(duì)于訂單的異步處理,采用的就是這種方式來做的,當(dāng)然這個(gè)只是用訂單流程來講解,用消息隊(duì)列來解決同步變異步,如果有其他的需求想做同步到異步的變換,我們都可以用這種方式,線程池這種方式在開發(fā)中是很少用的,寫起來比較麻煩,沒有用消息隊(duì)列來的更簡(jiǎn)單一些,這里我們重點(diǎn)再說一下解耦,解耦指的是誰呢,其實(shí)我們?cè)谥v上面的內(nèi)容,已經(jīng)說到了,就是解除訂單服務(wù)和其他服務(wù)之間的耦合度,特別是第一個(gè)圖里我們可以看到,訂單服務(wù)是直接拿到這三個(gè)平臺(tái)的接口的,也就是我現(xiàn)在訂單服務(wù)和其他服務(wù)是完全解耦的,那我們現(xiàn)在訂單服務(wù)和其他服務(wù)加了一層,這一層是誰呢,就是MQ系統(tǒng),通過MQ系統(tǒng)就解除了訂單服務(wù)和其他服務(wù)之間的一個(gè)耦合度,現(xiàn)在我訂單服務(wù)只管向MQ服務(wù)發(fā)送請(qǐng)求,然后MQ系統(tǒng)再向其他服務(wù)發(fā)送請(qǐng)求,所以就解除了訂單服務(wù)和其他服務(wù)之間的耦合度了,這就是用MQ系統(tǒng)和其他服務(wù)的耦合度,除了異步以外,還可以解決之間的耦合度,你接著往下走就可以,主要去解決的兩個(gè)問題,一個(gè)是同步變異步,還有就是解除服務(wù)之間的耦合度,最后還有一個(gè)就是流量削峰,我們消息隊(duì)列呢,還可以解決流量削峰的一個(gè)處理,比如舉個(gè)例子,我們有一些互聯(lián)網(wǎng)的電商平臺(tái),像秒殺這樣的活動(dòng),其實(shí)你想一想做一個(gè)秒殺,我們要有一個(gè)服務(wù)來處理秒殺,那么在這同一個(gè)時(shí)間,瞬間涌入上千個(gè)請(qǐng)求,上萬個(gè)請(qǐng)求,乃至幾十萬個(gè)請(qǐng)求,其實(shí)這個(gè)時(shí)候?qū)τ谀愕姆?wù)器來講,對(duì)于他的抗壓能力來講,會(huì)有很苛刻的要求的,一般這么大的請(qǐng)求量,你的服務(wù)器會(huì)宕掉,怎么解決這種抗壓的處理呢,我們可以在秒殺服務(wù)之前加一個(gè)消息隊(duì)列,所有的請(qǐng)求都交給消息隊(duì)列,因?yàn)橄㈥?duì)列他只是接收消息,他不處理消息,對(duì)于這個(gè)消息的處理,我們還是要交給秒殺服務(wù)去處理,所以正因?yàn)橛羞@樣的一個(gè)原因,所有的請(qǐng)求到消息隊(duì)列,到多少個(gè)請(qǐng)求以外我就不再處理請(qǐng)求了,你的請(qǐng)求可以過來,只是我不處理請(qǐng)求了,給客戶產(chǎn)生一個(gè)響應(yīng),但是對(duì)于秒殺服務(wù)就做了一個(gè)很好地保護(hù),然后消息隊(duì)列再把請(qǐng)求交給秒殺,秒殺服務(wù)再去做一個(gè)秒殺處理,所以我們要用消息隊(duì)列去做流量削峰,這都是消息中間件,所使用的這樣一個(gè)場(chǎng)景,在這里對(duì)消息中間件做一個(gè)介紹,當(dāng)然這個(gè)東西沒有一個(gè)標(biāo)準(zhǔn),必須得用消息隊(duì)列,這個(gè)完全根據(jù)自己的設(shè)計(jì)來決定,比如你有同步變異步的需求了,流量削峰的需求了,你完全可以加消息中間件,來解決相應(yīng)的問題,什么樣的場(chǎng)景去使用RabbitMQ,這樣我們?cè)偈褂肦abbitMQ的時(shí)候呢,大家應(yīng)該知道,也會(huì)變得更容易一些

?

總結(jié)

以上是生活随笔為你收集整理的为什么要用RabbitMQ的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。