這篇文章主要介紹“MQ消息隊列的概念是什么”的相關知識,小編通過實際案例向大家展示操作過程,操作方法簡單快捷,實用性強,希望這篇“MQ消息隊列的概念是什么”文章能幫助大家解決問題。
成都創(chuàng)新互聯(lián)公司是專業(yè)的瑪納斯網(wǎng)站建設公司,瑪納斯接單;提供網(wǎng)站設計、成都網(wǎng)站設計,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行瑪納斯網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!
一、消息隊列使用場景
1.1 常見的使用場景
系統(tǒng)解耦
在分布式環(huán)境下,系統(tǒng)間的相互依賴,最終會會導致整個依賴關系混亂,特別在微服務環(huán)境下,會出現(xiàn)相互依賴,甚至是循環(huán)依賴的情況,對后期系統(tǒng)的拆分和優(yōu)化都帶來極大負擔。那么我們就可以用MQ來進行處理。上游系統(tǒng)將數(shù)據(jù)投遞到MQ,下游系統(tǒng)取MQ的數(shù)據(jù)進行消費,投遞和消費可以用同步的方式處理,因為MQ接收數(shù)據(jù)的性能是非常高的,不會影響上游系統(tǒng)的性能。
異步處理
如果采用同步的方式,系統(tǒng)的性能(并發(fā)量,吞吐量,響應時間)會有瓶頸。如何解決這個問題呢?引入消息隊列,將不必要的業(yè)務邏輯異步處理。
異步處理也可以引來 并行處理的使用姿勢。在工作中,我們基于消息開發(fā)了一個簡單的分布式任務處理組件。該組件簡單分為三塊分別是 切分、加載、執(zhí)行三個階段
每個階段都是以作為消費者,然后處理完畢后再作為生產者發(fā)送消息。消息消費無狀態(tài),可以按需無限拓容。
流量削峰
由于使用消息,我們的鏈路變成了生產者發(fā)送消息,消息中間件存儲消息,最后消費者從消息中間件拉取消息的一個過程。而消息中間件的存儲能力能夠有效的幫助消費者進行緩沖。試想下,正常流量下消費者能夠愉快的進行消費,瞬時高峰流量來的時候,消費者消費能力跟不上,剛好阻塞在消息中間件,等峰值過后,消費者又能很快的將阻塞的消息進行消費。
流量削鋒也是消息隊列中的常用場景,一般在秒殺或團搶活動中使用廣泛!
數(shù)據(jù)分發(fā)
大部分開源的MQ中間件基本都支持一對多或者廣播的模式,而且都可以根據(jù)規(guī)則選擇分發(fā)的對象。這樣上游的一份數(shù)據(jù),眾多下游系統(tǒng)中,可以根據(jù)規(guī)則選擇是否接收這些數(shù)據(jù),這樣擴展性就很強了。
1.2 消息使用的先決條件
以上四種是MQ中間件最常見的場景,但是我們細想,MQ中間件的引入會帶來什么問題呢?那就是實時性。所以MQ中間件使用的先決條件是:能容忍延遲,只要求最終一致性較為合適。
二、消息相關的概念
MQ特點
先進先出
不能先進先出,都不能說是隊列了。消息隊列的順序在入隊的時候就基本已經確定了,一般是不需人工干預的。而且,最重要的是,數(shù)據(jù)是只有一條數(shù)據(jù)在使用中。 這也是MQ在諸多場景被使用的原因。
發(fā)布訂閱
發(fā)布訂閱是一種很高效的處理方式,如果不發(fā)生阻塞,基本可以當做是同步操作。這種處理方式能非常有效的提升服務器利用率,這樣的應用場景非常廣泛。
持久化
持久化確保MQ的使用不只是一個部分場景的輔助工具,而是讓MQ能像數(shù)據(jù)庫一樣存儲核心的數(shù)據(jù)。
分布式
在現(xiàn)在大流量、大數(shù)據(jù)的使用場景下,只支持單體應用的服務器軟件基本是無法使用的,支持分布式的部署,才能被廣泛使用。而且,MQ的定位就是一個高性能的中間件。
在JMS標準中,有兩種消息模型P2P(Point toPoint)和Publish/Sub(Pub/Sub)。
P2P
點對點,一個發(fā),一個消費。涉及到的角色 發(fā)布者(Publisher)、消費者(Consumer)、消息隊列(Queue)
特點
一個消息只能被一個消費者消費,消費后會從隊列里移除
發(fā)布者和消費者無關系,發(fā)布者發(fā)送消息的行為不會隨消費者而改變
消費者消費完成消息,需要向隊列Ack,消息隊列發(fā)現(xiàn)消息消費成功即做消息移除
Pub/Sub
發(fā)布訂閱模式,一個發(fā)布,多方訂閱。涉及到的角色有 發(fā)布者(Publisher)、主題(Topic)、訂閱者(Subscriber)。
特點
每個消息可以有多個消費者
針對某個主題(Topic)的訂閱者,必須創(chuàng)建一個訂閱者之后,才能消費發(fā)布者的消息
為了消費消息,訂閱者必須保持運行的狀態(tài)
三、常見問題及解決方案
消息阻塞
1、消息阻塞一般都是流量激增,超過消費者消費能力;
2、或者消費者出現(xiàn)邏輯問題,導致不斷的重試或長時間等待。
第一種可以通過擴容解決
第二種只能緊急修復問題,發(fā)布上線,在阻塞的過程中會造成大量的消息積壓,這種情況也可以考慮臨時擴容
重復消費
重復消費一般發(fā)生下消費端,比如消費者處理完畢,在準備進行ack的時候出現(xiàn)了問題,應用重啟后,消息中間件以為該消息還未處理又推給了消費者,或者消費者拉取的時候重復。
一般的做法是消費端做冪等。
消息丟失
消息丟失一般分為生產者發(fā)送失敗、消息中間件丟失、消費丟失。
生產者丟失:可能以為網(wǎng)絡問題或者消息中間處理失敗導致,消息遺漏。
消息中間的丟失:一般中間件可以設置丟棄策略,大部分MQ中間件產品可以保證數(shù)據(jù)不丟失,這種情況基本不用考慮。
消費丟失:有的消息中間件支持自動ack,當消費者消費到消息,消息中間件也不管是否消費成功自動ack。這時候一般選擇消費者主動ack比較合適。
消息順序性
消息順序性一般通過MQ中間件保證,大部分MQ中間件只能做到局部有序,比如Kafka,只能保證單個partition隊列有序。有些也會做到全局有序,但是成本比較高。筆者目前服務的公司現(xiàn)在是支持全局有序的。
關于“MQ消息隊列的概念是什么”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關的知識,可以關注創(chuàng)新互聯(lián)行業(yè)資訊頻道,小編每天都會為大家更新不同的知識點。