RocketMQ讀書筆記1 簡述

【訊息佇列的功能介紹】

分布式訊息佇列可以提**用解耦、流量削峰、訊息分發、保證最終一致性、方便動態擴容等功能。

【mq使用場景1——應用解耦】

複雜的系統如電商系統，會存在多個子系統，如訂單系統、庫存系統、物流系統、支付系統。如果各個子系統之間耦合性太強，會導致整體系統的可用性大幅降低，多個低錯誤率的子系統強耦合，會得到乙個高錯誤率的整體系統。

使用者建立訂單後，如果耦合地呼叫庫存系統、物流系統、支付系統，任何乙個子系統出現故障不可用，都會造成下單操作異常，影響使用者體驗。

[ 舉例——通過mq解耦應用，提高系統的可用性和穩定性 ]

基於訊息佇列的方式後，解耦各個應用，能提高系統的可用性。如果物流系統發生故障，需要幾分鐘來修復，在這幾分鐘裡，物流系統需要被處理的訂單資訊內容快取在訊息佇列中，使用者下單可以正常完成，當物流系統恢復後，補充處理儲存在佇列的訂單資訊即可，使用者感知不到物流系統發生過的幾分鐘故障。

【mq使用場景2——流量削峰】

秒殺活動，大部分的應用系統流量會瞬間猛增，這個時候沒有緩衝機制，系統要承受短時的大流量衝擊，通過訊息佇列，可以把大量的請求快取起來，讓系統合理處理這些請求，雖然系統的處理時間增長了，但是能大大提高系統的穩定性和使用者體驗。

[ 舉例——流量削峰提高系統的可用性 ]

比如，如果訂單系統每秒最多處理1w次下單，在秒殺活動時，可能短時間內，每秒有10w請求，為了保證系統的穩定性：

不加訊息佇列：

訂單超過1w次，就不允許使用者下單了。

加了訊息佇列：

可以取消1w這個限制，把請求快取在訊息佇列中，系統提高時長來處理，有的使用者請求可能會在下單十幾秒後才會收到下單成功的狀態，但是也比不能下單要好。

[ 小結 ]

使用訊息佇列進行流量削峰，很多使用是出於經濟考慮。有的業務系統，流量最高峰qps也不會超過1w的qps，而平時只有1k左右的qps，這種情況，可以考慮使用乙個普通效能的伺服器（只需支援1k左右的qps），然後加個訊息佇列作為高峰請求的緩衝，這樣可以節省很多資金。

【mq使用場景3——訊息分發】

在大資料這塊，資料的產生方會把各自的資料寫入乙個訊息佇列即可，資料的使用方根據各自的需求訂閱感興趣的資料，不同的資料團隊所訂閱的資料可以重複也可以不重複，互不干擾，也不必和資料產生方關聯。

[ 舉例——訊息分發 ]

各個子系統將日誌檔案不停寫入訊息佇列，不同的資料處理系統有各自的offset，互不影響。甚至某個團隊處理完的結果也可以寫入訊息佇列，作為資料的產生方，供其他團隊使用，避免重複計算。

【rocketmq的基本指令】

【1.啟動訊息佇列】

啟動nameserver

nohup sh bin/mqnamesrv &tail -f ~/logs/rocketmqlogs/namesrv.logthe name server boot success...

啟動broker

nohup sh bin/mqbroker -n localhost:9876&tail -f ~/logs/rocketmqlogs/broker.log

the broker[

%s, 192.168.0.233:10911] boot success...

【2.關閉訊息佇列】

關閉 nameserver

sh bin/mqshutdown broker
the mqbroker(
36695) is running...
send shutdown request to mqbroker(36695) ok

關閉 broker

sh bin/mqshutdown namesrv
the mqnamesrv(
36664) is running...
send shutdown request to mqnamesrv(36664) ok

【用命令列傳送和接受訊息】