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