消息隊列(MQ)是目前系統架構中主流方式,在大型系統及大數據中普遍採用。對任何架構或應用來講, MQ都是一個相當重要的組件。今天咱們就來細數MQ那些不得不說的好處。html
好處一:解耦安全
在項目啓動之初來預測未來項目會碰到什麼需求,是極其困難的。消息系統在處理過程當中間插入了一個隱含的、基於數據的接口層,兩邊的處理過程都要實現這一接口。這容許你獨立的擴展或修改兩邊的處理過程,只要確保它們遵照一樣的接口約束。服務器
好比咱們的貨款抵扣業務場景,用戶生成訂單發送MQ後當即返回,結算系統去消費該MQ進行用戶帳戶金額的扣款。這樣訂單系統只須要關注把訂單建立成功,最大可能的提升訂單量,而且生成訂單後當即返回用戶。而結算系統重點關心的是帳戶金額的扣減,保證帳戶金額最終一致。架構
好處二:冗餘框架
有些狀況下,處理數據的過程會失敗。除非數據被持久化,不然將形成丟失。MQ把數據進行持久化直到它們已經被徹底處理,經過這一方式規避了數據丟失風險。許多MQ所採用的"插入-獲取-刪除"範式中,在把一個消息從隊列中刪除以前,須要你的處理系統明確的指出該消息已經被處理完畢,從而確保你的數據被安全的保存直到你使用完畢。異步
好處三:擴展性分佈式
由於MQ解耦了你的處理過程,因此增大消息入隊和處理的頻率是很容易的,只要另外增長處理過程便可。就好比DMS分佈式消息服務,不須要改變代碼、不須要調節參數。擴展就像調大電力按鈕同樣簡單。大數據
好處四:靈活性和峯值處理能力優化
在訪問量劇增的狀況下,應用仍然須要繼續發揮做用,可是這樣的突發流量並不常見;若是爲以能處理這類峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用MQ可以使關鍵組件頂住突發的訪問壓力,而不會由於突發的超負荷的請求而徹底崩潰。htm
仍是以訂單系統和結算系統場景爲例,若是訂單系統經過RPC框架來調用結算系統,在有高峯促銷的狀況下生成訂單的量會很是大,並且因爲生成訂單的速度也很是快,這樣勢必會給結算系統形成系統壓力,服務器利用率則會偏高,但在不是高峯的時間點訂單量比較小,結算系統的服務器利用率則會偏低。對於結算系統來講就會出現下面這樣的高峯波谷現象圖。
那麼若是經過MQ的方式,將訂單存儲到MQ隊列中,消費端經過拉取的方式,而且拉去速度有消費端來控制,則就能夠控制流量趨於平穩。這樣對於結算系統來說,就達到了削峯填谷的目的。或者提及到了流控的目標
好處五:可恢復性
系統的一部分組件失效時,不會影響到整個系統。MQ下降了進程間的耦合度,因此即便一個處理消息的進程掛掉,加入隊列中的消息仍然能夠在系統恢復後被處理。
好處六:順序保證
在大多使用場景下,數據處理的順序都很重要。大部分MQ原本就是排序的,而且能保證數據會按照特定的順序來處理。Kafka保證一個Partition內的消息的有序性。
好處七:緩衝
在任何重要的系統中,都會有須要不一樣的處理時間的元素。例如,加載一張圖片比應用過濾器花費更少的時間。消息隊列經過一個緩衝層來幫助任務最高效率的執行———寫入隊列的處理會盡量的快速。該緩衝有助於控制和優化數據流通過系統的速度。
好處八:異步通訊
不少時候,用戶不想也不須要當即處理消息。消息隊列提供了異步處理機制,容許用戶把一個消息放入隊列,但並不當即處理它。想向隊列中放入多少消息就放多少,而後在須要的時候再去處理它們。
對系統而言,MQ消息隊列機制能承受更大訪問壓力;對架構而言,鬆耦合,系統維護性方便;而對用戶而言,想要系統訪問更快、系統體驗更好,天然首選DMS啦!