ActiveMQ
@Author:hanguixian
@Email:[email protected]
一 概述
- MQ產品：Kafka、RabbitMQ、RocketMQ、ActiveMQ …
1 前言
- 何種場景下使用消息中間件
- 爲什麼要在系統中引入消息中間件
2 背景
2.1系統之間直接調用–實際工程和存在的問題
- 微服務架構後，鏈式調用是我們在寫程序時候的一般流程，爲了完成一個整體功能會將其拆分成多個函數(或子模塊)，比如模塊A調用模塊B,模塊B調用模塊C，模塊C調用模塊D。但在大型分佈式應用中，系統間的RPC交互繁雜，一個功能背後要調用上百個接口並非不可能，從單機架構過渡到分佈式微服務架構的通例，這種架構會有哪些問題???
2.1.1 系統之間接口耦合嚴重
- 系統之間接口耦合比較嚴重，每新增一個下游功能，都要對上有的相關接口進行改造;
- 舉個例子:假如系統A要發送數據給系統B和C，發送給每個系統的數據可能有差異，因此係統A對要發送給每個系統的數據進行了組裝，然後逐一發送;
- 當代碼上線後又新增了一個需求:把數據也發送給D,新上了一個D系統也要接受A系統的數據。此時就需要修改A系統，讓他感知到D的存在，同時把數據處理好再給D。在這個過程中你會看到，每接入一個下游系統，都要對A系統進行代碼改造，開發聯調的效率很低。
- 其整體架構如下圖
2.2.2 面對大流量併發時，容易被沖垮
- 每個接口模塊的吞吐能力是有限的，這個上限能力如同堤壩，當大流量(洪水)來臨時，容易被沖垮。
舉個栗子秒殺業務:- 上游系統發起下單購買操作，我就是下單一個操作
- 下游系統完成秒殺業務邏輯(讀取訂單，庫存檢查，庫存凍結，餘額檢查，餘額凍結，訂單生成，餘額扣減，庫存扣減，生成流水，餘額解凍，庫存解凍)
2.1.3 等待同步存在性能問題
- RPC接口基本上是同步調用，整體的服務性能遵循“木桶理論”，即整體系統的耗時取決於鏈路中最慢的那個接口。比如A調用B/C/D都是50ms，但此時B又調用了B1，花費2000ms,那麼直接就拖累了整個服務性能。
2.2 解決方案
根據上述的幾個問題，在設計系統時可以明確要達到的目標:
- 能夠解耦：要做到系統解耦，當新的模塊接進來時，可以做到代碼改動最小
- 能夠削峯：設置流量緩衝池，可以讓後端系統按照自身吞吐能力進行消費，不被沖垮
- 能夠異步：強弱依賴梳理能將非關鍵調用鏈路的操作異步化並提升整體系統的吞吐能力
3 是什麼？
3.1 定義
- 面向消息的中間件(message-oriented middle ware)MOM能夠很好的解決以上問題。
- 是指利用高效可靠的消息傳遞機制進行與平臺無關的數據交流，並基於數據通信來進行分佈式系統的集成。
- 通過提供消息傳遞和消息排隊模型在分佈式環境下提供應用解耦、彈性伸縮、冗餘存儲、流量削峯、異步通信、數據同步等功能。
- 大致的過程是這樣的:
發送者把消息發送給消息服務器，消息服務器將消息存放在若干隊列/主題中，在合適的時候，消息服務器會將消息轉發給接受者。在這個過程中，發送和接受是異步的，也就是發送無需等待，而且發送者和接受者的生命週期也沒有必然關係: 尤其在發佈pub/訂閱sub模式下，也可以完成一對多的通信，即讓一個消息有多個接受者。
3.2 特點
3.2.1 採用異步處理模式
- 消息發送者可以發送一個消息而無須等待響應。消息發送者將消息發送到一條虛擬的通道(主題或隊列)上;
- 消息接收者則訂閱或監聽該通道。一條信息可能最終轉發給一個或多個消息接收者，這些接收者都無需對消息發送者做出同步迴應。整個過程都是異步的。
- 案例:也就是說，一個系統跟另外一個系統之間進行通信的時候，假如系統A希望發送一個消息給系統B，讓他去處理。但是系統A不關注系統B到底怎麼處理或者有沒有處理好，所以系統A把消息發送給MQ,然後就不管這條消息的“死活”了，接着系統B從MQ裏消費出來處理即可。至於怎麼處理，是否處理完畢，什麼時候處理，都是系統B的事兒，與系統A無關。
- 這樣的一種通信方式，就是所謂的“異步”通信方法，對於系統A來說，只要把消息發送給MQ，然後系統B就會異步去進行處理了，系統A不需要“同步”的等待系統B處理完。這樣的好處是什麼呢？解耦。
3.2.2 應用系統之間解耦合
- 發送者和接受者不必瞭解對方，只需要確認消息。
- 發送者和接受者不必同時在線。
4 作用
- 解耦
- 異步
- 削峯
5 下載
- ActiveMQ官網：http://activemq.apache.org/
6 內容
- 最重要的功能：實現高可用、高性能、可伸縮、易用和安全的企業級功能
- 異步消息的消費和處理
- 控制消息的消費順序
- 與spring/springboot整合
- MQ的集羣容錯
- …