消息中間件

一 :什麼是消息中間件：

• 　　沒有標準的定義，通常認爲消息中間件屬於分佈式系統的一個子系統，關注於數據的發送和接受，利用高效可靠的異步消息傳遞機制對分佈式系統其他子系統進行集成。

 

 

二:爲何使用消息中間件

1. 使各個系統之間解耦 
2. 增長異步處理能力
3. 增長系統緩衝能力
4. 增長系統的伸縮性
5. 增長系統的拓展性

三：消息中間件的經常使用使用方式

①異步處理

用戶註冊後，須要發註冊郵件和註冊短信,傳統的作法有兩種1.串行的方式;2.並行的方式

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

 

 

 

 

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

 

 

 

 

引入消息隊列後，把發送郵件,短信不是必須的業務邏輯異步處理

由此能夠看出,引入消息隊列後，用戶的響應時間就等於寫入數據庫的時間+寫入消息隊列的時間(能夠忽略不計),引入消息隊列後處理後,響應時間是串行的3倍,是並行的2倍。

 

②應用解耦

用戶下單後,訂單系統須要通知庫存系統,傳統的作法就是訂單系統調用庫存系統的接口.當庫存系統出現故障時,訂單就會失敗

 

 

 

 

引入消息隊列後

訂單系統:用戶下單後,訂單系統完成持久化處理,將消息寫入消息隊列,返回用戶訂單下單成功。

庫存系統:訂閱下單的消息,獲取下單消息,進行庫操做。

就算庫存系統出現故障,消息隊列也能保證消息的可靠投遞,不會致使消息丟失

 

③流量削峯

 

 

 秒殺活動，通常會由於流量過大，致使應用掛掉,爲了解決這個問題，通常在應用前端加入消息隊列。

1.能夠控制活動人數，超過此必定閥值的訂單直接丟棄

2.能夠緩解短期的高流量壓垮應用(應用程序按本身的最大處理能力獲取訂單)

1.用戶的請求,服務器收到以後,首先寫入消息隊列,加入消息隊列長度超過最大值,則直接拋棄用戶請求或跳轉到錯誤頁面.

2.秒殺業務根據消息隊列中的請求信息，再作後續處理.

 

 ④日誌處理

 

日誌處理是指將消息隊列用在日誌處理中，好比 Kafka 的應用，解決大量日誌傳輸的問題。架構簡化以下：
日誌採集客戶端，負責日誌數據採集，定時寫入 Kafka 隊列：Kafka 消息隊列，負責日誌數據的接收，存儲和轉發；日誌處理應用：訂閱並消費 kafka 隊列中的日誌數據

 

 

四：如何選擇消息中間件

 

 若是通常的業務系統要引入 MQ，怎麼選型：

用戶訪問量在 ActiveMQ 的可承受範圍內，並且確實主要是基於解耦和異步來用的，能夠考慮 ActiveMQ，也比較貼近 Java 工程師的使用習慣，可是 ActiveMQ 如今中止維護了，同時 ActiveMQ 併發不高，因此業務量必定的狀況下能夠考慮使用。

RabbitMQ 做爲一個純正血統的消息中間件，有着高級消息協議 AMQP 的完美結合，在消息中間件中地位無可取代，可是 erlang 語言阻止了咱們去深 入研究和掌控，對公司而言，底層技術沒法控制，可是確實是開源的，有比較穩定的支持，活躍度也高。

對本身公司技術實力有絕對自信的，能夠用 RocketMQ，可是 RocketMQ 誕生比較晚，而且更新迭代很快，這個意味着在使用過程當中有可能會遇到很 多坑，因此若是大家公司 Java 技術不是很強，不推薦使用。