2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

• 解耦?在項(xiàng)目啟動之初來預(yù)測將來項(xiàng)目會碰到什么需求，是極其困難的。消息系統(tǒng)在處理過程中間插入了一個隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過程都要實(shí)現(xiàn)這一接口。這允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

• 冗余有些情況下，處理數(shù)據(jù)的過程會失敗。除非數(shù)據(jù)被持久化，否則將造成丟失。消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險。許多消息隊(duì)列所采用的"插入-獲取-刪除"范式中，在把一個消息從隊(duì)列中刪除之前，需要你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你使用完畢。

• 擴(kuò)展性?因?yàn)橄㈥?duì)列解耦了你的處理過程，所以增大消息入隊(duì)和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調(diào)節(jié)參數(shù)。擴(kuò)展就像調(diào)大電力按鈕一樣簡單。

• 靈活性 & 峰值處理能力?在訪問量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見；如果為以能處理這類峰值訪問為標(biāo)準(zhǔn)來投入資源隨時待命無疑是巨大的浪費(fèi)。使用消息隊(duì)列能夠使關(guān)鍵組件頂住突發(fā)的訪問壓力，而不會因?yàn)橥话l(fā)的超負(fù)荷的請求而完全崩潰。

• 可恢復(fù)性?系統(tǒng)的一部分組件失效時，不會影響到整個系統(tǒng)。消息隊(duì)列降低了進(jìn)程間的耦合度，所以即使一個處理消息的進(jìn)程掛掉，加入隊(duì)列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。

• 順序保證 ?在大多使用場景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊(duì)列本來就是排序的，并且能保證數(shù)據(jù)會按照特定的順序來處理。Kafka能保證一個Partition內(nèi)的消息的有序性。

• 緩沖 ?在任何重要的系統(tǒng)中，都會有需要不同的處理時間的元素。例如，加載一張圖片比應(yīng)用過濾器花費(fèi)更少的時間。消息隊(duì)列通過一個緩沖層來幫助任務(wù)最高效率的執(zhí)行———寫入隊(duì)列的處理會盡可能的快速。該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度。

• 用于數(shù)據(jù)流 ?在一個分布式系統(tǒng)里，要得到一個關(guān)于用戶操作會用多長時間及其原因的總體印象，是個巨大的挑戰(zhàn)。消息系列通過消息被處理的頻率，來方便的輔助確定那些表現(xiàn)不佳的處理過程或領(lǐng)域，這些地方的數(shù)據(jù)流都不夠優(yōu)化。

• 異步通信 ?很多時候，用戶不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一個消息放入隊(duì)列，但并不立即處理它。想向隊(duì)列中放入多少消息就放多少，然后在需要的時候再去處理它們。

參考&引用：http://blog.iron.io/2012/12/top-10-uses-for-message-queue.html?spref=tw

轉(zhuǎn)載于:https://my.oschina.net/lenolong/blog/652623

總結(jié)

以上是生活随笔為你收集整理的为何使用消息系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。