1.RabbitMQ簡(jiǎn)介

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

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

2.RabbitMQ使用場(chǎng)景

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

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

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

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

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

介紹消息隊(duì)列：

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

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

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

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

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

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

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

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

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

(2)異步提高效率

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

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

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

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

(3)流量削峰

流量削峰也是消息隊(duì)列中常見(jiàn)的場(chǎng)景，一般用在秒殺或者群搶活動(dòng)中

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

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

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

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

優(yōu)勢(shì)

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

壞處

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

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

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

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

一致性問(wèn)題

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

概括

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