1.RabbitMQ簡介

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

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

2.RabbitMQ使用場景

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

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

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

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

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

介紹消息隊列：

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

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

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

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

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

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

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

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

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

(2)異步提高效率

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

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

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

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

(3)流量削峰

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

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

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

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

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

優(yōu)勢

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

壞處

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

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

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

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

一致性問題

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

概括

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