前言：關於消息隊列應該大家都不陌生,在實際的項目中消息隊列也無處不在,今天我和大家分享一下關於消息隊列的問題。
1、消息隊列定義
消息隊列大家又經常稱爲MQ(message queue),從字面的含義來看就是一個存放消息的容器。
2、消息隊列應用場景
2.1、異步處理
2.2、系統解耦
2.3、流量削峯
3、消息隊列順序性
提到mq那麼我們必然會討論mq順序性問題,比如生產者發送消息1,2,3...對於消費者必須按照1,2,3...這樣的順序來消費,那麼消息隊列應該怎麼樣去考慮這樣事情呢,有人說了消息隊列是先進先出不就保證了順序性,其實並非如此,而且想通過隊列來保證順序性是非常困難的,那麼我們來看看爲什麼說非常困難的。
對於生產者而言
比如生產者連續發送1、2、3但是不久2和3返回結果成功,唯獨1返回結果是失敗,這個時候如果我們重發1那麼順序肯定就會亂了。
對於存儲端而言
消息隊列不可能分區進行存儲,也就是一個topic的消息只能採用一個隊列存儲,如果一個topic採用多個隊列就不可能保證順序
對於消費者而言
對於消費端來說還不可以並行消費,也就是不可以開啓多線程或者多個客戶端來進行消費
3.1、消息隊列順序性分析1：
假設我們現在想要保證s1和s2兩條消息順序被消費可能想設計如上圖所示,假定生產者先發送s1然後在發送s2,如果想保證s1先被消費,那麼需要s1到達消費端後在通知mq2,然後mq2在發送消息。但是其實這是理想的模型,可能會出現如下2個問題
1、s1不一定要比s2先到mq集羣(比如網絡延遲)
2、s2到達mq集羣並且已經消費完畢,s1還沒到達mq集羣,這就會出現亂序
所有我們想要s1比s2先消費最簡單粗暴的方式就是s1和s2發送同一臺server上,這樣根據隊列先進先出原則,肯定s1要比s2先消費
3.2、消息隊列順序性分析2：
但是這種模型僅僅是理論上的可行,因爲可能出現網絡延遲,比如s2比是s1先到達消費端,我們同樣無法保證消息的順序,這樣一來我們可能發送s1等消費者響應後然後在發s2。
3.3、消息隊列順序性分析3：
但是我們知道消費者可能出現2種情況
1、消費者沒有響應(可能消費成功沒有響應,也可能消費失敗沒有響應)
2、消費者響應成功
對於沒有響應的mq集羣可以進行重發消息,如果消費成功重發就會導致消息重新處理,這樣一來就會帶來新的問題,重複問題下面說
綜上我們可以得出想保證消息順序性最簡單可行方式就是生產者->mq->消費者這樣一一對應關係,但是同樣會帶來如下2個問題
1、吞吐量不足
2、可用性低
3.4、消息隊列順序性分析4：
任何設計都離不開業務的本身,我們可以從業務來考慮順序消息
1、不關注亂序的應用實際大量存在
2、隊列無序不表示消息無序
註釋：對於同一種消息放入同一個隊列中,同一種消息可以通過topic主題來進行標記。
綜上我們可以可以總結出來爲了保證消息的順序性要從生產者、存儲端、消費者三個角度來考慮
1、生產端必須保證消息成功發送以後才能繼續發送第二條
2、存儲端必須要求同一種消息必須存放在同一個隊列中
3、消費端不可以採用併發消費
4、消息隊列重複性
消息重複由業務端來保證如上圖
5、消息隊列可靠性
生產者：ack確認機制消息重發
消費者：手動ack確認,消息重新請求,或者重試等
消息隊列：如下圖所示
1、對於業務方進行限流,避免惡意刷消息
2、服務器採用負載均衡避免一臺服務宕機而不可用
3、消息採用持久化,避免斷電等原因導致消息丟失
6、消息隊列存儲
消息隊列存儲一般採用邏輯存儲和物理存儲如下圖所示
1、邏輯存儲放入內存,主要存儲偏移量、消息主題等,同時將存儲內容刷入磁盤避免丟失
2、物理採用文件進行存儲,定期對文件進行歸檔
6、消息隊列的缺點
6.1、服務可用性降低
加入消息隊列後,如果出現mq集羣宕機,那麼就可能會導致服務不可用
6.2、服務複雜度增加
加入消息隊列以後就不得不考慮消息一致性、可靠性、重複性等問題無疑加大了服務的難度
歡迎工作一到五年的Java工程師朋友們加入Java架構開發： 854393687
羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！