RabbitMQ簡介

RabbitMQ是一個由erlang開發的基於AMQP（Advanced Message Queue ）協議的開源實現。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面都非常的優秀。是當前最主流的消息中間件之一。

簡介

RabbitMQ 是個訊息仲介（Message Broker）上面第一次提到時，您恐怕是一頭霧水。簡單說就是它協助我們傳遞交換訊息。您可以把它想成是郵局，當我們把信件丟到郵筒時，我們幾乎可以確定郵差先生最終一定會幫我們把信件送給收件者。以這個比喻來說 RabbitMQ 就是郵筒、郵局、郵差的集合體。

AMQP(Advanced Message Queue)

AMQP，是Application layer的一個開放標準，為面向消息的中間件設計。 消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在， 同樣，消息使用者也不用知道發送者的存在。

AMQP(BROKER)三大部分：EXCHANGE交換機，QUEUE隊列和BINDING綁定

Producer(client) / Exchange — binding — Queue (server/broker) / Consumer(client)

• Producing 就是傳送訊息。一個發送訊息的程式也被稱為 producer
• queue 佇列在 RabbitMQ 裡其實就是郵筒的意思。
• 雖然訊息在 RabbitMQ 和我們的應用程式之間傳遞但它們只會被存放在 queue。queue 本身只會被主機的記憶體和硬碟所限制，本質上就是一個很大的訊息緩衝區。可以有很多個 producer 發送，但它們都會傳到同一個 queue 並且可以有多個 consumer 可以從 queue 取得資料。
• Consuming 概略來說就是接收的意思。consumer 大致上說來就是一個等待接收訊息的程式。
• 現在我們介紹了產生者（producer）、接收者（consumer）、和仲介（broker）。它們並不需要存在同一台主機上，確實在大多的程式中也不是都放在一個機器上。

幾個概念說明:
Broker:它提供一種傳輸服務,它的角色就是維護一條從生產者到消費者的路線，保證數據能按照指定的方式進行傳輸
Exchange：消息交換機,它指定消息按什麼規則,路由到哪個隊列
Queue:消息的載體,每個消息都會被投到一個或多個隊列。
Binding:綁定，它的作用就是把exchange和queue按照路由規則綁定起來. Routing Key:路由關鍵字,exchange根據這個關鍵字進行消息投遞。
vhost:虛擬主機,一個broker里可以有多個vhost，用作不同用戶的權限分離。
Producer:消息生產者,就是投遞消息的程序
Consumer:消息消費者,就是接受消息的程序
Channel:消息通道,在客戶端的每個連接里,可建立多個channel.

訊息flow/Routing key

生產者產生msg給exchange, 根據routing key分配msg給不同的queue

綁定方式：direct(1 vs 1) / fanout(1 vs all) / topic(1 vs any)
Direct Exchange:直接匹配,通過Exchange名稱+RountingKey來發送與接收消息.
Fanout Exchange:廣播訂閱,向所有的消費者發布消息,但是只有消費者將隊列綁定到該路由器才能收到消息,忽略Routing Key.
Topic Exchange：主題匹配訂閱,這裡的主題指的是RoutingKey,RoutingKey可以採用通配符,如:*或#

應用場景

REF: https://blog.csdn.net/whoamiyang/article/details/54954780

異步處理 場景說明：用戶註冊後，需要發註冊郵件和註冊簡訊,傳統的做法有兩種1.串行的方式;2.並行的方式

(1)串行方式:將註冊信息寫入資料庫後,發送註冊郵件,再發送註冊簡訊,以上三個任務全部完成後才返回給客戶端。 這有一個問題是,郵件,簡訊並不是必須的,它只是一個通知,而這種做法讓客戶端等待沒有必要等待的東西.

(2)並行方式:將註冊信息寫入資料庫後,發送郵件的同時,發送簡訊,以上三個任務完成後,返回給客戶端,並行的方式能提高處理的時間。

假設三個業務節點分別使用50ms,串行方式使用時間150ms,並行使用時間100ms。雖然並性已經提高的處理時間,但是,前面說過,郵件和簡訊對我正常的使用網站沒有任何影響，客戶端沒有必要等著其發送完成才顯示註冊成功,應該是寫入資料庫後就返回.

(3)消息隊列 引入消息隊列後，把發送郵件,簡訊不是必須的業務邏輯異步處理 由此可以看出,引入消息隊列後，用戶的響應時間就等於寫入資料庫的時間+寫入消息隊列的時間(可以忽略不計),引入消息隊列後處理後,響應時間是串行的3倍,是並行的2倍。

應用解耦

場景：雙11是購物狂節,用戶下單後,訂單系統需要通知庫存系統,傳統的做法就是訂單系統調用庫存系統的接口.
這種做法有一個缺點: 當庫存系統出現故障時,訂單就會失敗。 因為 訂單系統和庫存系統高耦合.
引入消息隊列 訂單系統:用戶下單後,訂單系統完成持久化處理,將消息寫入消息隊列,返回用戶訂單下單成功。
庫存系統:訂閱下單的消息,獲取下單消息,進行庫操作。 就算庫存系統出現故障,消息隊列也能保證消息的可靠投遞,不會導致消息丟失

流量削峰 流量削峰一般在秒殺活動中應用廣泛
場景:秒殺活動，一般會因為流量過大，導致應用掛掉,為了解決這個問題，一般在應用前端加入消息隊列。
作用: 1.可以控制活動人數，超過此一定閥值的訂單直接丟棄
2.可以緩解短時間的高流量壓垮應用(應用程式按自己的最大處理能力獲取訂單)

1.用戶的請求,伺服器收到之後,首先寫入消息隊列,加入消息隊列長度超過最大值,則直接拋棄用戶請求或跳轉到錯誤頁面.
2.秒殺業務根據消息隊列中的請求信息，再做後續處理