本文來源於公眾號：胖滾豬學編程。轉載請註明出處！

一個風度翩翩，穿著格子襯衣的中年男子，拿著一個滿是劃痕的mac向她走來，看著錚亮的頭，胖滾豬心想，這肯定是尼瑪頂級架構師吧！完了要掛了。

結果面試官第一個問題，就讓胖滾豬內心暗喜

面試官：消息隊列這東西，你還熟悉吧？消息隊列在企業中的應用場景有哪些？

(這麼基礎的問題，手到擒來好嗎？原來阿裡不過如此。)

胖滾豬：嗯嗯，還挺熟悉的，可以用於流量削峰、應用解耦、非同步處理。

面試官：就這三種嗎？能不能再多說幾個應用。起碼八種吧。

(胖滾豬火冒三丈，尼瑪八種哪來的？玩我呢？但是出於禮貌，還是畢恭畢敬的回答面試官)

胖滾豬：額。。有這麼多嗎？不好意思，一時之間想不起來了呢。

面試官：哎。。大家都知道的我們不屑，就想聽聽不一樣的。回家去吧

胖滾豬內心挫敗，平時五毛錢都捨不得花的摳豬，豪擲100大洋打了飛車來到導師胖滾熊家裡求助。

胖滾熊：我先給你歸納了消息隊列八種場景，如圖所示，接下來我們再仔細說說每種場景的應用方案。

首先還是要介紹一下流量削峰、應用解耦、非同步處理的具體應用，雖然網上文章到處都有，不過畢竟它們是老大，老大不出場小二也不敢亂動。如果你很熟悉了，可以直接跳過！

應用解耦：

某電商系統架構如圖，用戶下單之後首先進入訂單系統，之後訂單系統又將訂單信息發送給物流系統和簡訊系統：

碼農胖滾豬很快就寫完了相關代碼：

        OrderInfo orderInfo = new OrderInfo();
        //省略組裝訂單信息
        sendToMessage(orderInfo);//發送給簡訊系統
        sendToLogistics(orderInfo);//發送給物流系統

一切就這麼平安無事過了大半月，領導又要搞啥實時大屏，實時展示當天訂單量，於是訂單系統又要將訂單信息發送給實時大屏系統

也沒關係，碼農胖滾豬又改了訂單系統的代碼，重新上線：

        OrderInfo orderInfo = new OrderInfo();
        //省略組裝訂單信息
        sendToMessage(orderInfo);//發送給簡訊系統
        sendToLogistics(orderInfo);//發送給物流系統
        sendToRealTimeSys();//發送給實時分析系統

隨著公司業務的壯大，訂單信息又要發送給監控系統、數據挖掘系統。。。這會胖滾豬不淡定了“到底何時是個頭呀！”

不僅如此，一旦下游某個系統異常，直接導致訂單系統也異常了，時常收到顧客的投訴 “你們這電商系統！不用了！”

嗨，胖滾豬，早知如此何必當初呢？在1.0版本你就不應該讓系統之間相耦合呀！如圖：

訂單系統只管將訂單信息發到消息隊列中，其他系統都從消息隊列中拿數據。這樣一來:

1、訂單系統再也不用關心誰要用了，即使增加、減少下游系統或是下游系統需求如何變化，訂單服務都無需做任何更改，實現了訂單服務與下游服務的解耦！可以一個人自由飛翔了~
2、其他系統即便掛了或者請求超時，都跟訂單系統無關，只跟消息隊列有關。

哇，這樣真是太爽了！和花錢一樣爽！

非同步處理

最近胖滾豬負責的用戶系統一直被投訴，原因是太慢了！點擊確認註冊之後要1s才返回結果。你看看人家阿裡的系統，點擊註冊10ms就可以返回結果了！

可是胖滾豬表示很無能為力，註冊之後要寫資料庫、要發簡訊、還要發郵件，你讓我怎麼快呢？阿裡的機器比我們好，才比我們快的！

嗨，胖滾豬，你可別把鍋甩給機器啊，明明是你自己的設計缺陷吶，看我給你改改：

這樣是不是覺得清爽了很多呢？？

註冊是主要的業務，而發簡訊和郵件通知用戶已經註冊成功是非主要的業務，甚至無關緊要，何必讓無關的東西影響主要的東西呢？
假設三個業務節點每個使用100ms，不考慮網路等其他開銷，則串列方式的時間是300ms，並行的時間可能是150ms。
透心涼心飛揚，這回省了不少時間，可以用來撩妹了。

流量削峰

胖滾豬在公司平安無事的呆了大半年，睡覺從沒被電話騷擾，直到2020.5.20這天，xx明星po出結婚照，瞬間幾千萬的流量，撐爆了微博，而明星同款520T恤的熱賣，也瞬間壓垮了胖滾豬的電商系統。

胖滾豬好吃好喝大半年，沒想到好日子還是終結了，半夜爬起來處理伺服器故障，第二天無精打采的，太難受了。。

嗨，胖滾豬，早知如此，當初就應該考慮仔細呀！一個電商系統，秒殺場景是遲早會出現的！

上下游對於事情的處理能力是不同的。比如，Web前端每秒承受上千萬的請求，並不是什麼神奇的事情。但資料庫的處理能力卻十分有限，即使使用SSD加分庫分表，單機的處理能力仍然在萬級。由於成本的考慮，我們不能奢求資料庫的機器數量追上前端。所以，利用中間系統轉儲兩個系統的通信內容，併在下游系統有能力處理這些消息的時候，再處理這些消息，是一套相對較通用的方式。

我們需要設計一套足夠健壯的架構來將後端的服務保護起來。設計思路是，使用消息隊列隔離網關和後端服務，以達到流量控制和保護後端服務的目的。

我再給你畫張圖吧：

這樣一來，用戶的請求，伺服器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面。而業務系統根據消息隊列中的請求信息，再做後續處理。

這種設計的優點是：能根據下游的處理能力自動調節流量，達到“削峰填谷”的作用

任務依賴

胖滾豬的公司有了高大上的數據中台，其中一個子系統叫做數據同步，只需要在前端頁面勾選表，就可以自助化完成mysql到hive的同步。

但其中有個節點是工單審核。在同步系統中發起表同步申請，首先會調用工單系統，領導層在工單系統審核成功後，同步系統才可以完成接下來的同步任務。最開始，胖滾豬是這麼設計的：

同步系統啟了一個定時任務，每五分鐘去查一下工單系統的介面，拿到審核結果。這種做法完全可行。

可是業務人員小甲不幹了，小甲是個急性子，他覺得太慢了！提個需求：必須要準實時！即領導審核成功後你要馬上給我同步！

這時候，胖滾豬又想到了消息隊列，靈機一動，有了2.0優化版本：

這下，小甲這種急性子也不用不耐煩了，只要領導一批准，馬上同步系統就會開始工作！

廣播

胖滾豬加入產品中心的第一天，就給了它一個任務：產品中心需要頻繁發佈產品變更，而關心產品的系統多達10來個。每次變更，都要聯調一次新介面，實在是太！麻！煩！了！

胖滾豬分析了一下，這就好像你媽喊你吃飯、還要喊你爸吃飯、喊你爺吃飯，她需要單獨給你們每個人發微信通知，有點麻煩。可是如果她直接在家族群@你們，就把消息廣播給大家了！

同理，產品系統相當於也要實現一個廣播的功能，產品變動之後需要廣播給其他系統。有了之前的經驗，很快想到了可以用消息隊列來實現。

在這裡，消息隊列就像我們的微信群一樣，有了消息隊列，我們只需要關心消息是否送達了隊列，至於誰關心它誰希望去訂閱，是下游的事情，無疑極大地減少了開發和聯調的工作量。

數據採集

胖滾豬又接了個數據採集的活，1、需要實時收集日誌、2、需要實時採集業務庫binlog。

經過一番調研，胖滾豬明白了，採集binlog一般用到canal、採集日誌一般可以用Flume和Logstash。

那麼採集之後數據丟到哪兒呢？胖滾豬看了看官方架構圖，咦，又有熟悉的消息隊列，原來消息隊列也可以用來數據採集呀！

所有主流的採集工具，都支持落地到Kafka等消息隊列。也就是說，消息隊列在數據採集這一塊，也有舉足輕重的作用。當然了，也不是必須要選擇消息隊列，要根據具體場景來選擇。如果要對接流計算任務，或者多個系統都需要用到採集到的數據，那麼選消息隊列就沒錯了；如果只是想單純存儲起來，比如一些日誌，那麼可以不用消息隊列。

連接流計算任務和數據

用消息隊列（主要指Kafka）來連接流計算任務和數據，這在大數據領域是非常通用的一個架構了。火爆的流計算框架，Flink和Spark都優先選擇Kafka作為數據源頭並提供了完美的支持。

我們看一下oppo的架構圖、簡直了。三次用到Kafka！這地位無敵了！為啥oppo要三次用到Kafka呢？我相信根據上面的應用場景和優勢你完全可以自行分析出來!

消息通訊

最後說一下消息通訊。。消息隊列可以應用在消息通訊中，比如聊天室。

你可能會吐槽，你這不廢話嗎？湊數呢？我當然知道消息隊列可用於消息通訊，小學生看名字都知道！

額，其實我只是想說明一下消息隊列在消息通訊的兩種場景罷了：點對點模型和發佈訂閱模型。

點對點通訊：系統 A 發送的消息只能被系統 B 接收，其他任何系統都不能讀取 A 發送的消息。日常生活的例子比如電話客服就屬於這種模型：同一個客戶呼入電話只能被一位客服人員處理，第二個客服人員不能為該客戶服務。

發佈 / 訂閱模型：與上面不同的是，它有一個主題（Topic）的概念，這個模型可能存在多個發佈者向相同的主題發送消息，而訂閱者也可能存在多個，它們都能接收到相同主題的消息。生活中的報紙訂閱就是一種典型的發佈 / 訂閱模型。

勁酒雖好,可不要貪杯哦

消息隊列確實有著非常廣泛的應用，但它也有缺點！勁酒雖好,可不要貪杯哦，貪杯會出問題的哦！

• 消息隊列會帶來一定的延遲問題；
• 降低了數據的一致性；如果要保證強一致性則需要高代價的補償，如分散式事務、對賬。
• 有數據丟失的風險；比如宕機重啟，如果要保證高可用需要額外的機制如雙活容災。

因此:

• 不適合要求實時響應的系統、
• 不適合要求數據強一致性的系統(比如直接和錢有關係的系統 銀行轉賬 第三方支付)、
• 不適合不能容忍數據丟失的系統

本文來源於公眾號：胖滾豬學編程。一枚集顏值與才華於一身的女程式媛。用漫畫形式讓編程so easy and interesting！求關註！
本文來源於公眾號【胖滾豬學編程】一個集顏值與才華於一身的女程式媛。以漫畫形式讓編程so easy and interesting。