我們已經成功的安裝了RabbitMQ,我們為什么要使用RabbitMQ,解決了什么問題,我們在安裝的時候,我們一般在我們的系統當中呢,通過RabbitMQ,或者消息中間件,不見得你非得用RabbitMQ,我們解決同步變異步的問題,那咱們先看什么是同步,我們那這個用例圖來看,比如一個用戶在使用我們的電商平臺的時候,他去購買了一個商品,并且下訂單了,這個時候肯定要向我們的訂單服務發送請求,比如這個時候他用時是50毫秒,然后訂單服務接收到請求以后呢,他還要去做其他服務的調用,比如我們要給用戶發短信,這個時候在我們的訂單服務當中,要去調用短信服務的接口,比如這個時候用時比如50毫秒,然后等短信發完了,訂單服務再往下走,再去調用Email服務,用戶發送Email,表示訂單創建成功,比如這個時候也是用時50毫秒,然后訂單服務去給App-push去發送請求,然后像我們的頁面也好,向其他的設備也好,比如這個時候又用時50毫秒,然后這一塊都完事了,最后返回給用戶,告訴他訂單創建成功,那么也就意味著,用戶下一個訂單,其實它總共耗時時間是200毫秒,因為我們下訂單以后,所有這些服務的調用,都是同步的,當這個服務處理完之后,再轉向下一個服務,等這些服務都處理完畢了,就會產生一個響應,并把訂單號發送給用戶,所以這個時候你會發現,用戶下訂單的時間,是比較長的,根據我們現在這個模型來看,他耗時200毫秒,并且服務和服務之間是強耦合,因為在訂單服務里去調的短信平臺,調的Email服務平臺的接口,所有的接口都在訂單服務當中,所以訂單服務和其他服務是緊耦合的,這是我們同步的一個現象,那么實際的電商平臺是這么設計的嗎,肯定不是,那我們怎么做的呢,我們要把同步的現象,給他改變成異步處理,怎么做異步處理呢,第一種方式,我們可以加線程池,當用戶去購買商品的時候,創建訂單,這個時候調用訂單服務,然后訂單服務當中呢,去線程池當中去啟動線程,我們都知道,線程它是啟動完之后,是不會等待其他線程執行完畢的,所以這是一個異步的,在線程池當中,啟動不同的線程操作或者調用不同平臺的接口,這樣也能將同步變成異步,就可以將同步轉換為異步,那么這么做有一個什么缺點呢,就是自己實現線程池,這個線程池就需要我們自己去編寫,并且他也是一個強耦合,因為線程池的代碼,訂單服務還是和這些服務是緊耦合的現象,所以這種方式雖然可以解決創建訂單時,與其他服務接口同步的問題,通過線程來變成異步,但是還沒有解決他們之間的耦合度的問題

就是借助于我們的消息隊列,這是什么意思呢,我們要在我們的訂單系統以外,再加一個MQ的系統,這個時候用戶在訂單的時候,還是訂單服務,訂單服務像MQ系統發請求,然后就不管了,直接返回給用戶,拿到一個訂單ID返回給他就可以了,至于MQ系統做什么,去調用各個服務的接口,發送信息,告訴他你在發短信了,這個時候MQ再去和其他系統做通信的時候,跟我們的訂單服務已經沒有關系了,因為他是完全獨立出來的一個系統,我們就直接給客戶端,返回一個響應就可以了,這樣就可以大大降低用戶創建所耗費的一個時間,同時還完成了跟其他服務的一個耦合度,所以我們一般在開發的過程當中,對于訂單的異步處理,采用的就是這種方式來做的,當然這個只是用訂單流程來講解,用消息隊列來解決同步變異步,如果有其他的需求想做同步到異步的變換,我們都可以用這種方式,線程池這種方式在開發中是很少用的,寫起來比較麻煩,沒有用消息隊列來的更簡單一些,這里我們重點再說一下解耦,解耦指的是誰呢,其實我們在講上面的內容,已經說到了,就是解除訂單服務和其他服務之間的耦合度,特別是第一個圖里我們可以看到,訂單服務是直接拿到這三個平臺的接口的,也就是我現在訂單服務和其他服務是完全解耦的,那我們現在訂單服務和其他服務加了一層,這一層是誰呢,就是MQ系統,通過MQ系統就解除了訂單服務和其他服務之間的一個耦合度,現在我訂單服務只管向MQ服務發送請求,然后MQ系統再向其他服務發送請求,所以就解除了訂單服務和其他服務之間的耦合度了,這就是用MQ系統和其他服務的耦合度,除了異步以外,還可以解決之間的耦合度,你接著往下走就可以,主要去解決的兩個問題,一個是同步變異步,還有就是解除服務之間的耦合度,最后還有一個就是流量削峰,我們消息隊列呢,還可以解決流量削峰的一個處理,比如舉個例子,我們有一些互聯網的電商平臺,像秒殺這樣的活動,其實你想一想做一個秒殺,我們要有一個服務來處理秒殺,那么在這同一個時間,瞬間涌入上千個請求,上萬個請求,乃至幾十萬個請求,其實這個時候對于你的服務器來講,對于他的抗壓能力來講,會有很苛刻的要求的,一般這么大的請求量,你的服務器會宕掉,怎么解決這種抗壓的處理呢,我們可以在秒殺服務之前加一個消息隊列,所有的請求都交給消息隊列,因為消息隊列他只是接收消息,他不處理消息,對于這個消息的處理,我們還是要交給秒殺服務去處理,所以正因為有這樣的一個原因,所有的請求到消息隊列,到多少個請求以外我就不再處理請求了,你的請求可以過來,只是我不處理請求了,給客戶產生一個響應,但是對于秒殺服務就做了一個很好地保護,然后消息隊列再把請求交給秒殺,秒殺服務再去做一個秒殺處理,所以我們要用消息隊列去做流量削峰,這都是消息中間件,所使用的這樣一個場景,在這里對消息中間件做一個介紹,當然這個東西沒有一個標準,必須得用消息隊列,這個完全根據自己的設計來決定,比如你有同步變異步的需求了,流量削峰的需求了,你完全可以加消息中間件,來解決相應的問題,什么樣的場景去使用RabbitMQ,這樣我們再使用RabbitMQ的時候呢,大家應該知道,也會變得更容易一些

?

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。