1、什麼是MQ

MQ(Message Quene) : 翻譯為訊息佇列，就是指儲存訊息的一個容器。它是一個典型的生產者和消費者模型，生產者不斷向訊息佇列中生產訊息，消費者不斷的從佇列中獲取訊息。訊息的生產和消費都是非同步的，而且只關心訊息的傳送和接收，沒有業務邏輯的侵入，可以輕鬆的實現系統間解耦。別名為：訊息中介軟體，通過利用高效可靠的訊息傳遞機制進行平臺無關的資料交流，並基於資料通訊來進行分散式系統的整合。

下面是MQ最簡單的模型，它包含了四個關鍵詞：生產者、消費者、訊息和佇列。

• 生產者：就是用於生產訊息的應用程式。
• 訊息：就是要傳輸的資料，可以是最簡單的文字字串，也可以是自定義的複雜格式（只要能按預定格式解析出來即可）。
• 佇列：大家應該再熟悉不過了，是一種先進先出資料結構。它是存放訊息的容器，訊息從隊尾入隊，從隊頭出隊，入隊即發訊息的過程，出隊即收訊息的過程。
• 消費者：就是用於讀取佇列中訊息的應用程式。

2、MQ的應用場景

使用訊息中介軟體最主要的目的：

• [1] 應用解耦
• [2] 非同步處理
• [3] 流量削峰

2.1 應用解耦

場景說明：使用者下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統呼叫庫存系統的介面。

傳統模式的缺點：

• 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗
• 由於訂單系統呼叫了庫存系統的介面，所以它們存在耦合

引入訊息佇列後的做法：

• 訂單系統：使用者下單後，訂單系統完成持久化處理，將訊息寫入訊息佇列，返回使用者訂單下單成功
• 庫存系統：訂閱下單的訊息，採用拉/推的方式，獲取下單資訊，庫存系統根據下單資訊，進行庫存操作
• 假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入訊息佇列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦
• 為了保證庫存肯定有，可以將佇列大小設定成庫存數量，或者採用其他方式解決。

2.2 非同步處理

場景說明：使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種 1.序列的方式；2.並行方式

(1) 序列方式：將註冊資訊寫入資料庫成功後，傳送註冊郵件，再發送註冊簡訊。以上三個任務全部完成後，返回給客戶端

(2) 並行方式：將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上三個任務完成後，返回給客戶端。與序列的差別是，並行的方式可以提高處理的時間

(3) 引入訊息佇列，將不是必須的業務邏輯，非同步處理。改造後的架構如下：

2.3 流量削峰

流量削鋒也是訊息佇列中的常用場景，一般在秒殺或團搶活動中使用廣泛。

應用場景：系統其他時間A系統每秒請求量就100個，系統可以穩定執行。系統每天晚間八點有秒殺活動，每秒併發請求量增至1萬條，但是系統最大的處理能力只能每秒處理1000個請求，於是系統崩潰，伺服器宕機。

傳統架構：大量使用者（100萬用戶）通過瀏覽器在晚上八點高峰期同時參與秒殺活動。大量的請求湧入我們的系統中，高峰期達到每秒鐘5000個請求，大量的請求打到MySQL上，每秒鐘預計執行3000條SQL。但是一般的MySQL每秒鐘扛住2000個請求就不錯了，如果達到3000個請求的話可能MySQL直接就癱瘓了，從而系統無法被使用。但是高峰期過了之後，就成了低峰期，可能也就1萬用戶訪問系統，每秒的請求數量也就50個左右，整個系統幾乎沒有任何壓力。

引入MQ：100萬用戶在高峰期的時候，每秒請求有5000個請求左右，將這5000請求寫入MQ裡面，系統A每秒最多隻能處理2000請求，因為MySQL每秒只能處理2000個請求。系統A從MQ中慢慢拉取請求，每秒就拉取2000個請求，不要超過自己每秒能處理的請求數量即可。MQ，每秒5000個請求進來，結果只有2000個請求出去，所以在秒殺期間（將近一小時）可能會有幾十萬或者幾百萬的請求積壓在MQ中。這個短暫的高峰期積壓是沒問題的，因為高峰期過了之後，每秒就只有50個請求進入MQ了，但是系統還是按照每秒2000個請求的速度在處理，所以說，只要高峰期一過，系統就會快速將積壓的訊息消費掉。我們在此計算一下，每秒在MQ積壓3000條訊息，1分鐘會積壓18萬，1小時積壓1000萬條訊息，高峰期過後，1個多小時就可以將積壓的1000萬訊息消費掉。

3、使用MQ的優缺點

訊息佇列的優點：

• 解耦：將系統按照不同的業務功能拆分出來，訊息生產者只管把訊息釋出到 MQ 中而不用管誰來取，訊息消費者只管從 MQ 中取訊息而不管是誰釋出的。訊息生產者和消費者都不知道對方的存在；
• 非同步：主流程只需要完成業務的核心功能；對於業務非核心功能，將訊息放入到訊息佇列之中進行非同步處理，減少請求的等待，提高系統的總體效能；
• 削峰/限流：將所有請求都寫到訊息佇列中，消費伺服器按照自身能夠處理的請求數從佇列中拿到請求，防止請求併發過高將系統搞崩潰；

訊息佇列的缺點：

• 系統的可用性降低：系統引用的外部依賴越多，越容易掛掉，如果MQ 伺服器掛掉，那麼可能會導致整套系統崩潰。這時就要考慮如何保證訊息佇列的高可用了；
• 系統複雜度提高：加入訊息佇列之後，需要保證訊息沒有重複消費、如何處理訊息丟失的情況、如何保證訊息傳遞的有序性等問題；
• 資料一致性問題：A 系統處理完了直接返回成功了，使用者都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那裡，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，就會導致資料不一致了；

4、不同MQ之間的區別

市場上常見的訊息佇列有如下：

• ActiveMQ：Apache出品，基於JMS，是最早使用的訊息佇列產品，時間比較長了，現在已經不再維護了。
• ZeroMQ：號稱最快的訊息佇列系統，尤其針對大吞吐量的需求場景。擴充套件性好，開發比較靈活，採用C語言實現，實際上只是一個socket庫的重新封裝，如果做為訊息佇列使用，需要開發大量的程式碼。
• RabbitMQ：基於AMQP協議，erlang語言開發，穩定性好
• RocketMQ：基於JMS，阿里開源的訊息中介軟體，純Java開發，具有高吞吐量、高可用性、適合大規模分散式系統應用的特點。
• Kafka：類似MQ的產品；分散式訊息系統，高吞吐量

注：每種MQ沒有絕對的好壞，主要依據使用場景，揚長避短，利用其優勢，規避其劣勢。

5、補充：QPS，TPS，PPV，UV，PR

[1]、QPS（Queries Per Second）：即每秒查詢率，是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。每秒查詢率：在因特網上，經常用每秒查詢率來衡量域名系統伺服器的機器的效能，即為QPS。對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。

[2]、TPS（Transactions Per Second）：每秒事務數，每秒系統能夠處理的事務次數。

[3]、PV（page view）：即頁面瀏覽量，或點選量；通常是衡量一個網路新聞頻道或網站甚至一條網路新聞的主要指標。對PV的解釋是，一個訪問者在24小時(0點到24點)內到底看了你網站幾個頁面。這裡需要強調：同一個人瀏覽你網站同一個頁面，不重複計算PV量，點100次也算1次。說白了，PV就是一個訪問者打開了你的幾個頁面。PV之於網站，就像收視率之於電視，從某種程度上已成為投資者衡量商業網站表現的最重要尺度。

PV的計算：當一個訪問著訪問的時候，記錄他所訪問的頁面和對應的IP，然後確定這個IP今天訪問了這個頁面沒有。如果你的網站到了23點，單純IP有60萬條的話，每個訪問者平均訪問了3個頁面，那麼pv表的記錄就要有180萬條。

[4]、UV(Unique Visitor)：指訪問某個站點或點選某條新聞的不同IP地址的人數。在同一天內，uv只記錄第一次進入網站的具有獨立IP的訪問者，在同一天內再次訪問該網站則不計數。獨立IP訪問者提供了一定時間內不同觀眾數量的統計指標，而沒有反應出網站的全面活動。

[5]、PR值：即PageRank，網頁的級別技術，用來標識網頁的等級/重要性。級別從1到10級，10級為滿分。PR值越高說明該網頁越受歡迎（越重要）。例如：一個PR值為1的網站表明這個網站不太具有流行度，而PR值為7到10則表明這個網站非常受歡迎（或者說極其重要）。

[6]、計算關係：

• QPS = 併發量 / 平均響應時間
• 併發量 = QPS * 平均響應時間
• 原理：每天80%的訪問集中在20%的時間裡，這20%時間叫做峰值時間。
• 公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS) 。
• 機器數量：峰值時間每秒QPS / 單臺機器的QPS = 需要的機器 。

參考資料：

• https://blog.csdn.net/whoamiyang/article/details/54954780