前言：關於消息隊列應該大家都不陌生,在實際的項目中消息隊列也無處不在,今天我和大家分享一下關於消息隊列的問題。
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、服務復雜度增加
加入消息隊列以后就不得不考慮消息一致性、可靠性、重復性等問題無疑加大了服務的難度