> 本文來源於公眾號：胖滾豬學程式設計。轉載請註明出處！  一個風度翩翩，穿著格子襯衣的中年男子，拿著一個滿是劃痕的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 intere