轉自：http://www.rzrgm.cn/LipeiNet/p/9877189.html     

作者：朝向遠方

作者博客：http://www.rzrgm.cn/LipeiNet/

前言：關于消息隊列應該大家都不陌生,在實際的項目中消息隊列也無處不在,今天我和大家分享一下關于消息隊列的問題。

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、服務復雜度增加

加入消息隊列以后就不得不考慮消息一致性、可靠性、重復性等問題無疑加大了服務的難度