RabbitMQ使用場景是什么

這篇文章主要介紹“RabbitMQ使用場景是什么”，在日常操作中，相信很多人在RabbitMQ使用場景是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”RabbitMQ使用場景是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

1.RabbitMQ簡介

MQ 稱為消息隊列。消息隊列 (RabbitMQ消息隊列)是一種應用程序到應用程序的通信方法。應用程序通過讀取和寫入進入和離開隊列的消息(應用程序的數據)進行通信，而無需專用連接來鏈接它們。消息傳遞是指程序之間通過消息中的數據進行通信，而不是直接相互調用進行通信。直接調用通常用于遠程過程調用等技術。隊列是指通過隊列進行通信的應用程序。隊列的使用消除了同時執行接收和發送應用程序的要求。

RabbitMQ 是一個開源的消息隊列系統，使用 Erlang 語言開發，基于 AMQP 協議實現。AMQP的主要特點是面向消息、隊列、路由(包括點對點和發布/訂閱)、可靠性和安全性。AMQP 協議在企業系統中使用較多。對于對數據一致性、穩定性和可靠性要求較高的場景，對性能和吞吐量的要求是次之。

2.RabbitMQ使用場景

(1)解耦(為面向服務的架構(SOA)提供基本的最終一致性實現)

場景描述：用戶下單后，訂單系統需要通知庫存系統。傳統的做法是訂單系統調用庫存系統的接口。

傳統模式的缺點：

如果庫存系統無法訪問，庫存的訂單減少將失敗，導致訂單失敗

訂單系統與庫存系統的耦合

介紹消息隊列：

訂單系統：用戶下單后，訂單系統完成持久化處理，將消息寫入消息隊列，成功返回用戶訂單

庫存系統：訂閱訂單信息，通過pull/push方式獲取訂單信息，庫存系統根據訂單信息進行庫存操作

如果：下單時庫存系統無法正常使用。不影響正常下單，因為下單后，訂單系統寫入消息隊列，不再關心其他后續操作。實現訂單系統和庫存系統的應用解耦

為了保證庫存肯定有，可以將隊列大小設置為庫存數量，或者用其他方法解決。

基于消息的模型關注的是“通知”而不是“處理”。

短信、郵件通知、緩存刷新等操作使用消息隊列進行通知。

消息隊列和RPC的區別和對比：

RPC：異步調用，及時獲取調用結果，具有強一致性結果，關心業務調用處理結果。

消息隊列：兩個異步RPC調用，將調用的內容轉儲到隊列中，選擇合適的時間進行投遞(移峰流量控制)

(2)異步提高效率

場景描述：用戶注冊后需要發送注冊郵件和注冊短信。傳統方式有兩種： 1. 串口方式;2.并聯模式

1)串口方式：成功將注冊信息寫入數據庫后，發送注冊郵件，然后發送注冊短信。以上三項任務完成后，返回客戶端

2)并行模式：注冊信息成功寫入數據庫后，注冊郵件與注冊短信同時發送。以上三項任務完成后，返回客戶端。與串行的區別在于并行方式會增加處理時間.

消息隊列的引入將不需要業務邏輯，異步處理。重構結構如下：

(3)流量削峰

流量削峰也是消息隊列中常見的場景，一般用在秒殺或者群搶活動中

應用場景：系統其他時間，系統A每秒有100個請求，系統可以穩定運行。系統每晚8點都有高峰活動，每秒并發請求數增加到10000，但系統最大處理能力每秒只能處理1000個請求，所以系統崩潰，服務器下跌降落。

以往架構：大量用戶(100萬用戶)通過瀏覽器在晚上8點高峰同時參與秒殺活動。大量請求涌入我們的系統。高峰期達到每秒 5000 個請求。大量請求命中 MySQL。估計每秒會執行3000條SQL。但是，一般的 MySQL 每秒可以處理 2000 個請求。如果達到3000個請求，MySQL可能會直接癱瘓，系統無法使用。然而，在高峰期之后，它變成了低峰期。可能只有10000個用戶訪問系統，每秒請求數只有50個左右，整個系統幾乎沒有壓力。

引入MQ：在100萬用戶的高峰期，每秒大約有5000個請求。將這 5000 個請求寫入 MQ。系統A每秒只能處理2000個請求，因為MySQL每秒只能處理2000個請求。要求。系統 A 從 MQ 緩慢拉取請求，每秒拉取 2000 個請求，不超過它每秒可以處理的請求數。MQ，每秒有5000個請求進來，但出去的請求只有2000個，所以在高峰期(近一個小時)，可能會有幾十萬甚至幾百萬的請求積壓在MQ中。

3.引入消息隊列的優缺點

優勢

優點是上述場景在特殊場景下都有相應的好處，比如解耦、異步、削峰。

壞處

降低系統可用性

系統引入的外部依賴越多，系統就越容易掛機。原來只是A系統調用了BCD的三個系統接口，ABCD的四個系統就可以正常運行，不會報錯。引入MQ之后，雖然ABCD系統沒有出錯，但是MQ掛掉之后整個系統也會崩潰。

增加系統復雜性

MQ引入后，需要考慮的問題更多。如何保證消息不被重復消費?如何保證消息不丟失?如何保證消息傳遞的順序?

一致性問題

系統A直接發送消息并返回成功，但是如果BCD系統出現系統寫庫失敗，就會出現數據不一致的情況。

概括

所以綜上所述，消息隊列是一個非常復雜的架構。引入它有很多優點，但必須做出各種額外的技術解決方案和架構，以避免它帶來的缺點。MQ系統的引入復雜度提高了一個數量級，但在某些場景下，復雜度是十倍一百倍，仍然需要MQ。

到此，關于“RabbitMQ使用場景是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！