牛逼哄哄的 RabbitMQ 到底有啥用？

一. RabbitMQ 簡介

MQ全稱為Message Queue, 消息隊列（MQ）是一種應用程序?qū)贸绦虻耐ㄐ欧椒ā贸绦蛲ㄟ^讀寫出入隊列的消息（針對應用程序的數(shù)據(jù)）來通信，而無需專用連接來鏈接它們。

消息傳遞指的是程序之間通過在消息中發(fā)送數(shù)據(jù)進行通信，而不是通過直接調(diào)用彼此來通信，直接調(diào)用通常是用于諸如遠程過程調(diào)用的技術。排隊指的是應用程序通過 隊列來通信。隊列的使用除去了接收和發(fā)送應用程序同時執(zhí)行的要求。

RabbitMQ是使用Erlang語言開發(fā)的開源消息隊列系統(tǒng)，基于AMQP協(xié)議來實現(xiàn)。AMQP的主要特征是面向消息、隊列、路由(包括點對點和發(fā)布/訂閱)、可靠性、安全。

AMQP協(xié)議更多用在企業(yè)系統(tǒng)內(nèi)，對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。

二. RabbitMQ 使用場景

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

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

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

• 假如庫存系統(tǒng)無法訪問，則訂單減庫存將失敗，從而導致訂單失敗

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

引入消息隊列

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

• 庫存系統(tǒng)：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫存系統(tǒng)根據(jù)下單信息，進行庫存操作

• 假如：在下單時庫存系統(tǒng)不能正常使用。也不影響正常下單，因為下單后，訂單系統(tǒng)寫入消息隊列就不再關心其他的后續(xù)操作了。實現(xiàn)訂單系統(tǒng)與庫存系統(tǒng)的應用解耦

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

基于消息的模型，關心的是“通知”，而非“處理”。

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

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

RPC: 異步調(diào)用，及時獲得調(diào)用結(jié)果，具有強一致性結(jié)果，關心業(yè)務調(diào)用處理結(jié)果。

消息隊列：兩次異步RPC調(diào)用，將調(diào)用內(nèi)容在隊列中進行轉(zhuǎn)儲，并選擇合適的時機進行投遞（錯峰流控）

2. 異步提升效率

場景說明：用戶注冊后，需要發(fā)注冊郵件和注冊短信。傳統(tǒng)的做法有兩種?

1.串行的方式；2.并行方式

（1）串行方式：將注冊信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊郵件，再發(fā)送注冊短信。以上三個任務全部完成后，返回給客戶端

（2）并行方式：將注冊信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊郵件的同時，發(fā)送注冊短信。以上三個任務完成后，返回給客戶端。與串行的差別是，并行的方式可以提高處理的時間

（3）引入消息隊列，將不是必須的業(yè)務邏輯，異步處理。改造后的架構(gòu)如下：

3. 流量削峰

流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。關于秒殺系列文章可以關注公眾號Java技術棧獲取閱讀。

應用場景：系統(tǒng)其他時間A系統(tǒng)每秒請求量就100個，系統(tǒng)可以穩(wěn)定運行。系統(tǒng)每天晚間八點有秒殺活動，每秒并發(fā)請求量增至1萬條，但是系統(tǒng)最大的處理能力只能每秒處理1000個請求，于是系統(tǒng)崩潰，服務器宕機。

之前架構(gòu)：大量用戶（100萬用戶）通過瀏覽器在晚上八點高峰期同時參與秒殺活動。大量的請求涌入我們的系統(tǒng)中，高峰期達到每秒鐘5000個請求，大量的請求打到MySQL上，每秒鐘預計執(zhí)行3000條SQL。

但是一般的MySQL每秒鐘扛住2000個請求就不錯了，如果達到3000個請求的話可能MySQL直接就癱瘓了，從而系統(tǒng)無法被使用。但是高峰期過了之后，就成了低峰期，可能也就1萬用戶訪問系統(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個請求進來，結(jié)果只有2000個請求出去，所以在秒殺期間（將近一小時）可能會有幾十萬或者幾百萬的請求積壓在MQ中。

這個短暫的高峰期積壓是沒問題的，因為高峰期過了之后，每秒就只有50個請求進入MQ了，但是系統(tǒng)還是按照每秒2000個請求的速度在處理，所以說，只要高峰期一過，系統(tǒng)就會快速將積壓的消息消費掉。

我們在此計算一下，每秒在MQ積壓3000條消息，1分鐘會積壓18萬，1小時積壓1000萬條消息，高峰期過后，1個多小時就可以將積壓的1000萬消息消費掉。

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

優(yōu)點

優(yōu)點就是以上的那些場景應用，就是在特殊場景下有其對應的好處，解耦、異步、削峰。

缺點

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

• 系統(tǒng)的復雜性提高
  引入了MQ之后，需要考慮的問題也變得多了，如何保證消息沒有重復消費？如何保證消息不丟失？怎么保證消息傳遞的順序？

• 一致性問題
  A系統(tǒng)發(fā)送完消息直接返回成功，但是BCD系統(tǒng)之中若有系統(tǒng)寫庫失敗，則會產(chǎn)生數(shù)據(jù)不一致的問題。

總結(jié)

所以總結(jié)來說，消息隊列是一種十分復雜的架構(gòu)，引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構(gòu)來規(guī)避。

引入MQ系統(tǒng)復雜度提升了一個數(shù)量級，但是在有些場景下，就是復雜十倍百倍，還是需要使用MQ。