作者：海向
出處：www.cnblogs.com/haixiang/p/10199754.html
一. RabbitMQ 簡介
MQ全稱為Message Queue, 訊息佇列（MQ）是一種應用程式對應用程式的通信方法，應用程式通過讀寫出入佇列的訊息（針對應用程式的資料）來通信，而無需專用連接來鏈接它們，
訊息傳遞指的是程式之間通過在訊息中發送資料進行通信，而不是通過直接呼叫彼此來通信，直接呼叫通常是用于諸如遠程程序呼叫的技術，排隊指的是應用程式通過 佇列來通信，佇列的使用除去了接收和發送應用程式同時執行的要求，
RabbitMQ是使用Erlang語言開發的開源訊息佇列系統，基于AMQP協議來實作，AMQP的主要特征是面向訊息、佇列、路由(包括點對點和發布/訂閱)、可靠性、安全，
AMQP協議更多用在企業系統內，對資料一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次，
二. RabbitMQ 使用場景
1. 解耦（為面向服務的架構（SOA）提供基本的最終一致性實作）
場景說明：用戶下單后，訂單系統需要通知庫存系統，傳統的做法是，訂單系統呼叫庫存系統的介面，
傳統模式的缺點：
-
假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗
-
訂單系統與庫存系統耦合
引入訊息佇列
-
訂單系統：用戶下單后，訂單系統完成持久化處理，將訊息寫入訊息佇列，回傳用戶訂單下單成功
-
庫存系統：訂閱下單的訊息，采用拉/推的方式，獲取下單資訊，庫存系統根據下單資訊，進行庫存操作
-
假如：在下單時庫存系統不能正常使用，也不影響正常下單，因為下單后，訂單系統寫入訊息佇列就不再關心其他的后續操作了，實作訂單系統與庫存系統的應用解耦
-
為了保證庫存肯定有，可以將佇列大小設定成庫存數量，或者采用其他方式解決，
基于訊息的模型，關心的是“通知”，而非“處理”，
短信、郵件通知、快取重繪等操作使用訊息佇列進行通知，
訊息佇列和RPC的區別與比較：
RPC: 異步呼叫，及時獲得呼叫結果，具有強一致性結果，關心業務呼叫處理結果，
訊息佇列：兩次異步RPC呼叫，將呼叫內容在佇列中進行轉儲，并選擇合適的時機進行投遞（錯峰流控）
2. 異步提升效率
場景說明：用戶注冊后，需要發注冊郵件和注冊短信，傳統的做法有兩種
1.串行的方式；2.并行方式
（1）串行方式：將注冊資訊寫入資料庫成功后，發送注冊郵件，再發送注冊短信，以上三個任務全部完成后，回傳給客戶端
（2）并行方式：將注冊資訊寫入資料庫成功后，發送注冊郵件的同時，發送注冊短信，以上三個任務完成后，回傳給客戶端，與串行的差別是，并行的方式可以提高處理的時間
（3）引入訊息佇列，將不是必須的業務邏輯，異步處理，改造后的架構如下：
3. 流量削峰
流量削鋒也是訊息佇列中的常用場景，一般在秒殺或團搶活動中使用廣泛，關于秒殺系列文章可以關注公眾號Java技術堆疊獲取閱讀，
應用場景：系統其他時間A系統每秒請求量就100個，系統可以穩定運行，系統每天晚間八點有秒殺活動，每秒并發請求量增至1萬條，但是系統最大的處理能力只能每秒處理1000個請求，于是系統崩潰，服務器宕機，
之前架構：大量用戶（100萬用戶）通過瀏覽器在晚上八點高峰期同時參與秒殺活動，大量的請求涌入我們的系統中，高峰期達到每秒鐘5000個請求，大量的請求打到MySQL上，每秒鐘預計執行3000條SQL，
但是一般的MySQL每秒鐘扛住2000個請求就不錯了，如果達到3000個請求的話可能MySQL直接就癱瘓了，從而系統無法被使用，但是高峰期過了之后，就成了低峰期，可能也就1萬用戶訪問系統，每秒的請求數量也就50個左右，整個系統幾乎沒有任何壓力，
引入MQ：100萬用戶在高峰期的時候，每秒請求有5000個請求左右，將這5000請求寫入MQ里面，系統A每秒最多只能處理2000請求，因為MySQL每秒只能處理2000個請求，
系統A從MQ中慢慢拉取請求，每秒就拉取2000個請求，不要超過自己每秒能處理的請求數量即可，MQ，每秒5000個請求進來，結果只有2000個請求出去，所以在秒殺期間（將近一小時）可能會有幾十萬或者幾百萬的請求積壓在MQ中，
這個短暫的高峰期積壓是沒問題的，因為高峰期過了之后，每秒就只有50個請求進入MQ了，但是系統還是按照每秒2000個請求的速度在處理，所以說，只要高峰期一過，系統就會快速將積壓的訊息消費掉，
我們在此計算一下，每秒在MQ積壓3000條訊息，1分鐘會積壓18萬，1小時積壓1000萬條訊息，高峰期過后，1個多小時就可以將積壓的1000萬訊息消費掉，
三. 引入訊息佇列的優缺點
優點
優點就是以上的那些場景應用，就是在特殊場景下有其對應的好處，解耦、異步、削峰，
缺點
-
**系統的可用性降低
**系統引入的外部依賴越多，系統越容易掛掉，本來只是A系統呼叫BCD三個系統介面就好，ABCD四個系統不報錯整個系統會正常運行，引入了MQ之后，雖然ABCD系統沒出錯，但MQ掛了以后，整個系統也會崩潰， -
**系統的復雜性提高
**引入了MQ之后，需要考慮的問題也變得多了，如何保證訊息沒有重復消費？如何保證訊息不丟失？怎么保證訊息傳遞的順序？ -
**一致性問題
**A系統發送完訊息直接回傳成功，但是BCD系統之中若有系統寫庫失敗，則會產生資料不一致的問題，
總結
所以總結來說，訊息佇列是一種十分復雜的架構，引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避，
引入MQ系統復雜度提升了一個數量級，但是在有些場景下，就是復雜十倍百倍，還是需要使用MQ，
近期熱文推薦：
1.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
2.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看，，
3.吊打 Tomcat ，Undertow 性能很炸！！
4.國人開源了一款超好用的 Redis 客戶端，真香！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/95720.html
標籤：Java
上一篇：Mac部署spark2.4.4