RabbitMQ使用場景是什么

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

1.RabbitMQ簡介

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

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

2.RabbitMQ使用場景

(1)解耦(為面向服務(wù)的架構(gòu)(SOA)提供基本的最終一致性實現(xiàn))

場景描述：用戶下單后，訂單系統(tǒng)需要通知庫存系統(tǒng)。傳統(tǒng)的做法是訂單系統(tǒng)調(diào)用庫存系統(tǒng)的接口。

傳統(tǒng)模式的缺點：

如果庫存系統(tǒng)無法訪問，庫存的訂單減少將失敗，導(dǎo)致訂單失敗

訂單系統(tǒng)與庫存系統(tǒng)的耦合

介紹消息隊列：

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

庫存系統(tǒng)：訂閱訂單信息，通過pull/push方式獲取訂單信息，庫存系統(tǒng)根據(jù)訂單信息進行庫存操作

如果：下單時庫存系統(tǒng)無法正常使用。不影響正常下單，因為下單后，訂單系統(tǒng)寫入消息隊列，不再關(guān)心其他后續(xù)操作。實現(xiàn)訂單系統(tǒng)和庫存系統(tǒng)的應(yīng)用解耦

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

基于消息的模型關(guān)注的是“通知”而不是“處理”。

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

消息隊列和RPC的區(qū)別和對比：

RPC：異步調(diào)用，及時獲取調(diào)用結(jié)果，具有強一致性結(jié)果，關(guān)心業(yè)務(wù)調(diào)用處理結(jié)果。

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

(2)異步提高效率

場景描述：用戶注冊后需要發(fā)送注冊郵件和注冊短信。傳統(tǒng)方式有兩種： 1. 串口方式;2.并聯(lián)模式

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

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

消息隊列的引入將不需要業(yè)務(wù)邏輯，異步處理。重構(gòu)結(jié)構(gòu)如下：

(3)流量削峰

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

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

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

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

3.引入消息隊列的優(yōu)缺點

優(yōu)勢

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

壞處

降低系統(tǒng)可用性

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

增加系統(tǒng)復(fù)雜性

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

一致性問題

系統(tǒng)A直接發(fā)送消息并返回成功，但是如果BCD系統(tǒng)出現(xiàn)系統(tǒng)寫庫失敗，就會出現(xiàn)數(shù)據(jù)不一致的情況。

概括

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

到此，關(guān)于“RabbitMQ使用場景是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>