消息隊列與快遞櫃之間的奇妙關係

提到消息隊列可能一些朋友經常聽別人說起一些名詞,比如:服務程序解耦,處理流量削峯,通過異步處理提升用戶體驗,緩衝批處理提高處理性能。筆者擅於白話解說,所以我就不用專業的術語去解釋專業的問題了。我一直覺得消息隊列的功能和快遞櫃的功能非常相似,怎麼個相似法呢?讓我來詳細給你說說。

一、白話消息隊列

我們來將快遞櫃與消息隊列做一個對比

  • 消息隊列比作快遞櫃:有很多廠家生產快遞櫃,如:豐巢(apache kafka),速遞易(alibaba RocketMQ),近鄰寶(ActiveMQ)等等,反正常用的就這幾個。快遞櫃負責臨時保存郵件,消息隊列負責臨時保存消息數據。
  • 快遞員比作消息生產者:快遞員負責向快遞櫃投遞郵件,生產者負責向消息隊列投遞消息。異曲同工之妙啊!
  • 消費者比作消息消費者: 可能是這個例子太貼切了,以至於這句怎麼看都是廢話。廢話也還是要說,生活中的消費者取郵件,程序中的消費者取消息數據。

二、快遞櫃(消息隊列)帶來的好處

我們先回顧一下在沒有快遞櫃的日子裏是怎麼度過的:某天早上突然接到快遞員電話:"兄弟,有你的快遞啊"。心裏想真糟糕:“你早不來晚不來,我馬上就要上班了,你這個時候來。好吧,我等你一會”。結果有可能快遞員很不靠譜,一會說堵車,一會說馬上到,等來等去你上班遲到了。這種情況讓你很崩潰!

突然有一天,小區裏突然出現了一個叫做快遞櫃的東西,這東西好啊。"兄弟,有你快遞啊",心想誰是你兄弟:"啊,你放快遞櫃裏面吧,我晚上下班回來取"。快遞員愉快的把快遞放入快遞櫃,開始打下一個電話,一早上10個郵件。如果每個都送上門快遞員最少要半小時。現在好了,9個放快遞櫃,1個用戶要求送上門,10分鐘就搞定了。快遞員覺得這個東東真的很好!

快遞員高興了,消費者用戶其實也很滿意,有的購物狂一天有可能收10來個郵件。沒有快遞櫃的時候,快遞員來一個電話就去取一次(等一次)快遞。有了快遞櫃,下班的時候就一起全都取了。上面的例子,體現了消息隊列(快遞櫃)的幾個優越性,請讀者仔細品評:

  • 異步解耦:有了快遞櫃,消費者不用等待快遞員,用戶體驗增強。消費者與生產者(快遞員)之間解耦,不會因爲對方的操作行爲,影響自己獨立處事的程序。用戶不用疲於等待與接收事件阻塞耗時。
  • 流量削峯:我們假定一種極端的情況,你通過各個渠道買了1000本書,突然某一小時集中的給你打電話。你肯定不具備一個小時收1000個郵件的能力,所以你讓快遞員將郵件放入快遞櫃。所以你就可以按照自己的處理能力,按照自己的時間安排去取郵件。同樣我們的消費者程序在面臨多用戶、高併發的請求情況下,將數據放入消息隊列保存可以將流量數據削峯,按照程序能夠處理的能力和資源進行數據消費。
  • 緩衝批處理:生產者批量投遞,爽!消費者一次性取多個郵件,爽!

三、引入快遞櫃帶來的缺點

說了這麼多的優點,那麼快遞櫃有沒有缺點呢?當然有

  1. 引入複雜度。毫無疑問,快遞櫃(消息隊列)這東西是多出來的,在原來的收取過程中是不存在的。所以需要地方放它,還需要防火、防盜防潮,需要去維護它。消息隊列中間件也是一樣的,你需要服務器區安裝它,還要對它進行維護。

  2. 會導致暫時的數據不一致。 如果沒有快遞櫃,你收到了郵件件就是真的收到了。但是使用快遞櫃之後,你收到了"郵件放入快遞櫃的消息",但是與你真的取到郵件這中間會有一定的延時。當然你最終還是會取到郵件,選擇"消息隊列"快遞櫃,就是要忍受暫時不一致,接受"最終一致性"。

  3. 當然極端情況下,快遞櫃壞了,你要不可避免地接受"郵件可能會丟失"的事實,對於安保係數高的小區這幾乎不會發生。

歡迎關注我的博客,更多精品知識合集

本文轉載註明出處(必須帶連接,不能只轉文字):字母哥博客 - zimug.com

覺得對您有幫助的話,幫我點贊、分享!您的支持是我不竭的創作動力!。另外,筆者最近一段時間輸出瞭如下的精品內容,期待您的關注。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章