訊息佇列的使用場景是怎樣的？ - 祁達方的回答 - 知乎 https://www.zhihu.com/question/34243607/answer/14073217 訊息佇列的主要特點是非同步處理，是將比較耗時或不需要即時（同步）返回結果的操作作為訊息放入訊息佇列。 主要的好處： 1、解耦：每個成員不必受其他成員影響，可以獨立自主，只是通過一箇中間件來聯絡，不會因為某個服務元件出現問題，而影響到整個系統的效能。 2、提速：訊息生產者只需要把訊息傳給MQ就好，後續就不用管了，節省了訊息生產者的時間。 3、削峰：對於訊息消費方，把短時間內的高負載分散到更長的時間裡來處理。服務元件通過訊息中介軟體給別的元件發訊息，別的元件即時當前沒空處理，等到空閒時看到這個訊息，就可以處理了。

4、廣播：如果訊息佇列使用的是釋出/訂閱的模式的話，那麼訊息生產者只需釋出一次，多個訂閱者就可以從佇列中讀取訊息，不需釋出多次。

一般服務元件間進行通訊，都是通過暴露資料介面的方式，這種通訊方式比較直接，但系統之間的耦合度會比較高。如果系統的服務元件很多，互相呼叫起來，整個系統的介面呼叫關係會很複雜。通過訊息中介軟體來通訊的話，系統元件間的耦合度就大大降低。所以， 訊息中介軟體的最主要的作用是解耦 。 另外每個服務元件的處理能力和承擔的負載都是不同的，有些元件可能正忙得不亦樂乎，已經沒法再接收新的請求，而有些元件現在可能根本就不線上，但不能讓其他的元件都等著它。比較好的做法就是通知某個元件，你幫我幹什麼事情，幹完了再回復我一下，也就是非同步的方式。這樣就不會因為某個服務元件出現問題，而影響到整個系統的效能。 MQ vs Webservice Webservice When you use a web service you have a client and a server: 1.If the server fails the client must take responsibility to handle the error. 2.When the server is working again the client is responsible of resending it. 3.If the server gives a response to the call and the client fails the operation is lost. 4.You don't have contention, that is: if million of clients call a web service on one server in a second, most probably your server will go down. 5.You can expect an immediate response from the server, but you can handle asynchronous calls too. MQ When you use a message queue like RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo you expect different and more fault tolerant results: 1.If the server fails, the queue persist the message (optionally, even if the machine shutdown). 2.When the server is working again, it receives the pending message. 3.If the server gives a response to the call and the client fails, if the client didn't acknowledge the response the message is persisted. 4.You have contention, you can decide how many requests are handled by the server (call it worker instead). 5.You don't expect an immediate synchronous response, but you can implement/simulate synchronous calls.
MQ的工作模式 主要有兩種工作模式：一種是 生產者/消費者 （Producer/Consumer）模式；另一種是 釋出/訂閱 （Pub/Sub）模式。 生產/消費模式中有兩種角色，訊息生產者（Producer）負責生產訊息，並把訊息傳送到佇列中，然後訊息消費者（Consumer）從佇列中取出並且消費訊息。 訊息被消費以後，佇列中就不再儲存，所以其他消費者不可能消費到已經被消費的訊息。 換句話說，存在多個消費者的情況下，對一個訊息而言，只會有一個消費者可以消費它，所以生產/消費模式又稱為 點對點（P2P）模式 。

生產/消費模式是一種一對一的訊息傳遞方式 在釋出/訂閱模式中，訊息釋出者（Publisher）將訊息釋出到某個主題（topic），同時有多個訊息訂閱者（Subscriber）會接收到該訊息。和點對點方式不同，釋出到主題的訊息會被所有該主題的訂閱者接收到，這是一種1對多的訊息傳遞方式。
釋出/訂閱模式是一種一對多的訊息傳遞方式
訊息佇列應用場景 以下介紹訊息佇列在實際應用中常用的使用場景：非同步處理，應用解耦，流量削鋒和訊息通訊四個場景。 1、非同步處理 場景說明：使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種：序列的方式和並行方式。 序列方式 ：將註冊資訊寫入資料庫成功後，傳送註冊郵件，再發送註冊簡訊。以上三個任務全部完成後，返回給客戶。 並行方式 ：將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上三個任務完成後，返回給客戶端。與序列的差別是，並行的方式可以提高處理的時間。 假設三個業務節點每個使用50毫秒鐘，不考慮網路等其他開銷，則序列方式的時間是150毫秒，並行的時間可能是100毫秒。 因為CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次。則序列方式1秒內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）。 小結 ：如以上案例描述，傳統的方式系統的效能（併發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？ 引入訊息佇列，將不是必須的業務邏輯，非同步處理。改造後的架構如下： 按照以上約定，使用者的響應時間相當於是註冊資訊寫入資料庫的時間，也就是50毫秒。註冊郵件，傳送簡訊寫入訊息佇列後，直接返回，因此寫入訊息佇列的速度很快，基本可以忽略，因此使用者的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20QPS。比序列提高了3倍，比並行提高了兩倍！ 2、應用解耦 場景說明：使用者下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統呼叫庫存系統的介面。如下圖： 傳統模式的缺點： 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗，訂單系統與庫存系統耦合。 如何解決以上問題呢？引入應用訊息佇列後的方案，如下圖： 訂單系統：使用者下單後，訂單系統完成持久化處理，將訊息寫入訊息佇列，返回使用者訂單下單成功 庫存系統：訂閱下單的訊息，採用拉/推的方式，獲取下單資訊，庫存系統根據下單資訊，進行庫存操作 假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入訊息佇列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。 3、流量削鋒 流量削鋒也是訊息佇列中的常用場景，一般在秒殺或團搶活動中使用廣泛！ 應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入訊息佇列。 可以控制活動的人數，可以緩解短時間內高流量壓垮應用。 使用者的請求，伺服器接收後，首先寫入訊息佇列。假如訊息佇列長度超過最大數量，則直接拋棄使用者請求或跳轉到錯誤頁面。 秒殺業務根據訊息佇列中的請求資訊，再做後續處理。 4、日誌處理 日誌處理是指將訊息佇列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。架構簡化如下： 日誌採集客戶端，負責日誌資料採集，定時寫受寫入Kafka佇列；Kafka訊息佇列，負責日誌資料的接收，儲存和轉發；日誌處理應用：訂閱並消費kafka佇列中的日誌資料。 以下是新浪kafka日誌處理應用案例： Kafka ：接收使用者日誌的訊息佇列； Logstash ：做日誌解析，統一成JSON輸出給Elasticsearch； Elasticsearch ：實時日誌分析服務的核心技術，一個schemaless，實時的資料儲存服務，通過index組織資料，兼具強大的搜尋和統計功能； Kibana ：基於Elasticsearch的資料視覺化元件，超強的資料視覺化能力是眾多公司選擇ELK stack的重要原因。 5、訊息通訊 訊息通訊是指，訊息佇列一般都內建了高效的通訊機制，因此也可以用在純的訊息通訊。比如實現點對點訊息佇列，或者聊天室等。 點對點通訊： 客戶端A和客戶端B使用同一佇列，進行訊息通訊。 聊天室通訊： 客戶端A，客戶端B，客戶端N訂閱同一主題，進行訊息釋出和接收。實現類似聊天室效果。 以上實際是訊息佇列的兩種訊息模式，點對點或釋出訂閱模式。模型為示意圖，供參考。
訊息中介軟體產品 市場上出現過很多商用訊息中介軟體產品，比如Sun的JMS等，還有很多開源訊息引擎，比如ActiveMQ、Kafka等。另外像阿里、騰訊這樣的大公司往往會開發自己的訊息中介軟體，之所以要自己做，是因為這些大公司的業務場景相對固化，需要追求的是更高的效能。 中小公司一般沒有能力造輪子，採用通用的開源產品是比較合適的。另外也可以使用阿里雲、騰訊雲這些雲服務商的訊息中介軟體產品。下面列舉一些目前用的比較多的開源訊息中介軟體。 （1）ActiveMQ/ApolloMQ ActiveMQ是Apache出品的最流行的開源訊息匯流排，同時也是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現，使用Java語言編寫。作為老牌訊息佇列，可謂歷史悠久，但歷史包袱也比較多。最新架構的產品為ApolloMQ。 （2）Kafka Kafka是LinkedIn開源的分散式釋出-訂閱訊息系統，目前歸屬於Apache頂級專案。Kafka主要特點是基於Pull的模式來處理訊息消費，追求高吞吐量，設計目標就是用於日誌收集和傳輸。 Kafka生態完善，其程式碼是用Scala語言編寫，並且有很多不同程式語言的介面，尤其適合海量訊息傳遞。 （3）RabbitMQ RabbitMQ是一個在AMQP基礎上完成的，可複用的企業訊息系統。他遵循Mozilla Public License開源協議。由Erlang語言編寫。 AMQP協議更多用在企業系統內，對資料一致性、穩定性和可靠性要求很高的場景，對效能和吞吐量的要求還在其次。 （4）RocketMQ 這是由阿里開源的一款高效能、高吞吐量的訊息中介軟體。與Kafka類似，同樣專為海量訊息傳遞打造，主張使用拉模式，天然的叢集、HA、負載均衡支援。可以說RocketMQ包含了阿里十年來在電商中介軟體架構設計上積累的最寶貴的經驗。
Kafka、RabbitMQ、RocketMQ訊息中介軟體的對比 —— 訊息傳送效能 對比Kafka、RabbitMQ、RocketMQ傳送小訊息(124位元組)的效能。這次壓測我們只關注服務端的效能指標,所以壓測的標準是:
不斷增加發送端的壓力,直到系統吞吐量不再上升,而響應時間拉長。這時服務端已出現效能瓶頸,可以獲得相應的系統最佳吞吐量。 來源： Kafka、RabbitMQ、RocketMQ訊息中介軟體的對比 —— 訊息傳送效能
參考 Message Queue (MQ) Testing 訊息佇列的使用場景是怎樣的？ 聊聊雲端計算：最簡單易懂的訊息中介軟體教程 Message Queue vs. Web Services?  Kafka、RabbitMQ、RocketMQ訊息中介軟體的對比 —— 訊息傳送效能 訊息佇列常見的使用場景