天天看點

消息隊列 | 初探消息隊列——rocketMQ簡單示例

rocketmq簡單示例

在微服務遍地開花的今天,消息隊列的應用特别廣泛,但在此之前,我對消息隊列的認知僅僅停留在是什麼和能幹什麼的認知,沒有使用過任何一款消息隊列,對它的實際應用也沒有任何認知,但是從現在市場上的技術情況來說,消息隊列已經是一個web後端開發必須掌握的核心元件之一,是以我就利用空閑時間來了解下,今天我們分享的是rocketmq,同樣也是阿裡巴巴開源的一個元件,2016年阿裡巴巴把它捐贈給了apache開源基金會,目前是該基金會的頂級項目之一。

在開始正文之前,我們先來看下消息隊列的一些知識。

消息隊列簡單來講,它就類似于存放消息的容器,消息生産者将消息放入消息隊列中,消費者從消息隊列中拿出消息進行消費(比如寫訂單)。消息隊列是分布式系統中重要的元件,使用消息隊列主要是為了通過異步處理提高系統性能和削峰、降低系統耦合性。目前使用較多的消息隊列有activemq,rabbitmq,kafka,rocketmq。

随着網際網路業務需求的不斷發展,傳統的架構模式已經無法滿足需求,特别是在電商業務大發展的當下更是如此。為了應對這種百萬并發、千萬并發甚至億級數量的并發,這種并發模式的特點是并發量集中出現在某一時間段,比如雙十一、雙十二或者促銷、打折日,而其他時間的并發量是峰值并發量的十分之一,甚至百分之一,如果按照峰值的并發量來設計系統架構,不僅初投資大耗費巨資,而且在日常運作維護也很燒錢。為了平衡這兩種情況下的并發量,同時降低系統建設成本,消息隊列這樣的系統元件應運而生。

簡單來說,消息隊列就是一種平衡系統并發量的系統元件,主要的作用就是削峰填谷。我們假設這張圖中紅色表示沒有加入消息隊列元件的系統并發時序圖(這裡的圖是随意畫的,隻是為了說明問題),藍色表示架構中加入了消息隊列元件:

消息隊列 | 初探消息隊列——rocketMQ簡單示例

對比之後我們會發現,我們發現引入消息隊列元件之後,降低了訂單系統的峰值并發量,就相當于我們将一部分峰值請求的業務處理,放在系統壓力小時去處理,當然實際過程中訂單系統一直在有條不紊地處理消息隊列中的訂單資訊,直到所有訂單處理完成。當然,它主要是針對一些實時性要求不強但并發量大的業務,比如購票、搶購下單等允許稍後推送處理結果的業務。

我們來想象這樣一個應用場景,我們要做一個購票系統,購票成功後要短信告知使用者購票結果,如果采用串行方式(也就是同步調用),我們的調用方式是這樣的:使用者送出購票訂單後,訂單系統受理購票訂單後,調用短信系統發送購票結果。這裡我們放一個圖,大家就更清楚了:

消息隊列 | 初探消息隊列——rocketMQ簡單示例

串行架構下系統的響應時間是150ms + 150ms,需要300ms,從業務流程上來說,訂單受理成功後發送購票結果,這沒有什麼問題,但是如果短信系統在某個時間段内系統當機,短信服務不可用,購票短信無法發送,最終導緻的結果是使用者是無法下單的,不僅影響使用者體驗,也影響公司的業務受益。

而且再深入分析下這個業務流程,你會發現短信是否發送與使用者送出訂單的操作是沒有關系的,使用者需要知道的隻是它的訂單是否處理成功,至于發送購票成結果的短信,對整個業務而言并發核心業務,就算短信發送失敗,也不應該影響購票業務。

是以,我們更合理的業務處理方式是,訂單系統受理成功後,直接将受理結果傳回給使用者,至于訂單的處理結果,可以等整個業務完成後生成,然後訂單系統向短信系統發送訂單處理結果的消息,短信系統收到消息後給給使用者發購票結果,這裡我們存放消息的容器就是消息隊列,這時候我們的系統機構是這樣的:

消息隊列 | 初探消息隊列——rocketMQ簡單示例

上面這種架構中,我們發送短信的業務是異步的,這樣不僅可以減少使用者等待的時間,提高服務的響應效率,如果省去短信系統的處理時間,那麼最終業務的響應時間就縮減為150ms,而且這種架構下系統的耦合性更低,比如如果未來業務需求發送變化,不僅需要給使用者發送短信,還要将結果推送到微信公衆号,業務耗時100ms,甚至還需要将結果以郵件的方式發送到使用者,業務耗時150ms,如果還是第一種架構模式,那使用者要等待的響應時長是150ms + 150ms + 100ms + 150ms,但對第二種架構,使用者的響應時間始終是150ms:

消息隊列 | 初探消息隊列——rocketMQ簡單示例

目前最新的版本是4.8,下面傳送門:

消息隊列 | 初探消息隊列——rocketMQ簡單示例

點選上圖的位址,紅框内的位址是推薦的國内的鏡像位址,下載下傳比較快

解壓下載下傳的zip檔案

直接壓縮軟體解壓即可

這裡windows需要設定,linux并不需要,當然我也沒有在linux環境下測試,有興趣的小夥伴自己去試驗。在windows添加如下環境變量:

消息隊列 | 初探消息隊列——rocketMQ簡單示例

或者在啟動前的powershell視窗裡設定,這裡是臨時,每次都要設定,嫌麻煩的直接設定永久的:

linux

windows

打開powershell,如果沒有設定環境環境變量需要先執行下面的操作,進行環境變量設定

然後進入rocketmq安裝目錄,執行如下操作

消息隊列 | 初探消息隊列——rocketMQ簡單示例
消息隊列 | 初探消息隊列——rocketMQ簡單示例

和上面啟動name服務一樣,沒設定環境需要先執行前面兩行環境變量設定的操作

然後執行啟動操作

操作之前,一定要進入rocketmq安裝目錄,否則回報如下紅色錯誤

消息隊列 | 初探消息隊列——rocketMQ簡單示例

同樣的,沒設定環境變量的記得先設定,嫌麻煩就直接設定永久的環境變量,參照設定環境變量

執行指令後,會看到我們向消息隊列中發送了很多消息

消息隊列 | 初探消息隊列——rocketMQ簡單示例

同樣的,沒設定環境變量的記得先設定

執行上面指令後,可以看到控制台接收到剛才發送的消息

消息隊列 | 初探消息隊列——rocketMQ簡單示例

這裡的demo在官網都可以看到,也都很簡單,需要補充說明的,我會停下來解釋。開始項目之前,先引入如下依賴:

單向消息就是沒有傳回值的消息

順序消息簡單來說,就是消費者的消費順序和生産者生産順序是一緻的,比如對下面代碼中的建立訂單,消費的時候肯定是先消費建立1,然後是建立2,再是建立3,這裡的是區分是否是同一類消息,是通過message的tag屬性的值來判斷的。關于順序消息借用網上的一個圖來說明吧:

消息隊列 | 初探消息隊列——rocketMQ簡單示例

這篇文章,從昨天寫到今天,今天在完善内容的時候,寫到了我們最近服務更新的一次翻車事故,由于篇幅問題我把它單獨抽出來了,有興趣的小夥伴去看看吧,看我們咋翻車的,還有我們的血淚教訓。

在今天的内容中,我們主要介紹了什麼是消息隊列、消息隊列的作用,以及rocketmq的安裝部署和它的java示例。因為目前,我也在學習和研究,是以就先分享到這裡,後面等我深入了解之後再來分享,主要是現在已經不早了,再六分鐘午夜十二點,晚安吧!