rocketmq中專業(yè)術(shù)語、消息隊列需要解決的問題

今天就跟大家聊聊有關(guān)rocketmq中專業(yè)術(shù)語、消息隊列需要解決的問題，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

專業(yè)術(shù)語：

• Producer： 消息生產(chǎn)者，負責產(chǎn)生消息，一般由業(yè)務(wù)系統(tǒng)負責產(chǎn)生消息

• Consumer： 消息消費者，負責消費消息，一般是后臺系統(tǒng)負責異步消費

• Push Consumer：
  Consumer的一種，應(yīng)用通常向Consumer對象注冊一個Listener接口，一旦收到消息，Consumer對象立刻回調(diào)Listener接口方法

• Pull Consumer：
  Consumer的一種，通常主動調(diào)用Consumer的拉消息方法從broker拉消息，主動權(quán)由應(yīng)用控制

• Producer Group：
  一類Producer的集合名稱，這類Producer通常發(fā)送一類消息，且發(fā)送邏輯一致

• Consumer Group：
  一類Consumer的集合名稱，這類Consumer通常發(fā)送一類消息，且發(fā)送邏輯一致

• Broker：
  消息中轉(zhuǎn)角色，負責存儲消息，轉(zhuǎn)發(fā)消息，一般也稱為Server。在JMS規(guī)范中稱為Provider

• 廣播消費：
  一條消息被多個Consumer消費，即使這些Consumer屬于同一個Consumer Group，消息也會被Consumer Group中的每個Consumer都被消費一次，廣播消費中的Consumer Group概念可以認為在消息 劃分方面無意義。 在CORBA Notification規(guī)范中，消費方式都屬于廣播消費 在JMS規(guī)范中，相當于JMS publish/subscribe model

• 集群消費：
  一個Consumer Group中的實例平均分攤消費消息。例如某個topic有9條消息，其中一個Consumer Group有3個實例（可能是三個進程或者3臺機器），那么每個實例只能消費其中3條消息

• 順序消息：
  消費消息的順序要同發(fā)送消息的順序一致，在RocketMq中，主要指的是局部順序，即一類消息為滿足順序性，必須Producer單線程順序發(fā)送，且發(fā)送到同一個隊列，這樣Consumer就可以按照 Producer發(fā)送的順序去消費消息。

• 普通順序消息：
  順序消息的一種，正常情況下可以保證完全的順序消息，但是一旦發(fā)生通信異常，Broker重啟，由于隊列總數(shù)發(fā)生變化，哈希取模后定位的隊列會變化，產(chǎn)生短暫的消息隊列順序不一致。
  如果業(yè)務(wù)能容忍在集群異常情況（如某個Broker宕機或者重啟）下，消息短暫的亂序，使用普通順內(nèi)需方式比較合適。

• 嚴格順序消息：
  順序消息的一種，無論正常異常情況都能保證順序，但是犧牲了分布式FailOver特性，即Broker集群中要有一臺機器不可用，則整個集群都不可用，服務(wù)可用性大大降低
  如果服務(wù)器部署為同步雙寫模式，此缺陷可通過備機自動切換為主避免，不過仍然會存在幾分鐘服務(wù)不可用。（依賴同步雙寫，主備自動切換，自動切換功能還未實現(xiàn)） 目前已知的應(yīng)用只有數(shù)據(jù)庫binlog同步強依賴嚴格順序消息，其他應(yīng)用絕大部分都可以容忍短暫亂序，推薦使用普通順序消息。

• Message Queue
  在RocketMq中，所有消息隊列都是持久化，長度無限的數(shù)據(jù)結(jié)構(gòu)，所謂長度無限是指隊列中的每個存儲單元都是定長，訪問其中的存儲單元使用offset來訪問，offset為java long類型，64位，理論上在100年 內(nèi)不會溢出，所以認為長度無限，另外隊列中只保存最近幾天的數(shù)據(jù)，之前的數(shù)據(jù)會按照過期時間來刪除。 也可以認為Message Queue是一個長度無限的數(shù)組，offset就是下標。

消息隊列需要解決哪些問題：

1、Publish/Subscribe

發(fā)布訂閱消息是消息中間件的最基本的功能，也是相對于傳統(tǒng)的RPC而言

2、Message Priority（消息優(yōu)先級）

規(guī)范中描述的優(yōu)先級是指在一個消息隊列中，每條消息都有不同的優(yōu)先級，一般用整數(shù)來描述，優(yōu)先級高的消息先投遞，如果消息完全在一個內(nèi)存隊列中，那么在投遞前可以按照優(yōu)先級排序，令優(yōu)先級高的先投遞。 由于Rocketmq所有消息都是持久化的，所以如果按照優(yōu)先級來排序，開銷會非常大，因此RocketMq沒有特意支持消息優(yōu)先級，但是可以通過變通的方式實現(xiàn)類似功能，即單獨配置一個優(yōu)先級高的隊列，和一個普通 優(yōu)先級的隊列，將不同優(yōu)先級發(fā)送到不同的隊列即可。 對于優(yōu)先級問題可以歸納為2類：
1）只要達到優(yōu)先級目的即可，不是嚴格意義上的優(yōu)先級，通常將優(yōu)先級劃分為高、中、低，或者再多幾個級別。每個優(yōu)先級可以用不同的topic表示，指定不同topic來表示優(yōu)先級，這種方式可以解決一部分優(yōu)先級問題， 但是對業(yè)務(wù)的優(yōu)先級精確性做了妥協(xié)。
2）嚴格的優(yōu)先級，優(yōu)先級用整數(shù)表示，例如：0~65535，這種優(yōu)先級問題一般使用不同topic解決就非常不合適。如果讓MQ解決此問題，會對MQ性能造成非常大的影響。這里要確保一點，業(yè)務(wù)上是否需要這種嚴格的優(yōu)先級， 如果將優(yōu)先級壓縮成幾個，對業(yè)務(wù)影響有多大？

3、Message Order（消息順序）

消息有序指的是一類消息消費時，能按照發(fā)送順序來消費。例如：一個訂單產(chǎn)生了3條消息，分別是訂單創(chuàng)建，訂單付款，訂單完成。消費時，要按照這個順序消費才能有意義。但是同時訂單之間是可以并行消費的。 RocketMq可以嚴格的保證消息有序。

4、Message Filter

Broker端消息過濾： 在Broker中，按照Consumer的要求做過濾，優(yōu)點是減少了對于Consumer無用消息的網(wǎng)絡(luò)傳輸。缺點是增加了Broker的負擔，實現(xiàn)相對復雜
1）淘寶Notify支持多種過濾方式，包含按照消息類型過濾，靈活的語法表達式過濾
2）淘寶RocketMQ支持按照簡單的MessageTag過濾，也支持按照Message Header、body進行過濾

5、Message Persistence(消息持久化)

消息中間件通常采用的幾種持久化方式：
1）持久化到數(shù)據(jù)庫，例如mysql
2）持久化到kv存儲，例如levelDB、伯克利DB等kv存儲系統(tǒng)
3）文件記錄形式持久化，例如kafka，rocketmq
4) 對內(nèi)存數(shù)據(jù)做一個持麗化鏡像，例如 beanstalkd，VisiNotify
1）2）3）三種持久方式都具有將內(nèi)存隊列Buffer進行擴展的能力，4）只是一個內(nèi)存鏡像，作用是當broker掛掉重啟后仍然能將之前內(nèi)存的數(shù)據(jù)恢復出來
Rocketmq參考了kafka的持久化方式，充分利用Linux文件系統(tǒng)內(nèi)存cache提高性能

6、Message Reliablity（消息的可靠性）

影響消息可靠性的幾種情況: (1) Broker 正常關(guān)閉
(2) Broker 異常 Crash（崩潰）
(3) OS Crash
(4) 機器掉電，但是能立即恢復供電情況。
(5) 機器無法開機(可能是cpu、主板、內(nèi)存等關(guān)鍵設(shè)備損壞)
(6) 磁盤設(shè)備損壞。
1）2）3）4）四種情況都屬于硬件資源可立即恢復情況，Rocketmq在這四種情況下能保證消息不丟，后者丟失少量數(shù)據(jù)（依賴刷盤方式是同步還是異步）
5）6）屬于單點故障，且無法恢復，一旦發(fā)生，在此單點上的消息全部丟失。RocketMQ在這兩種情況下，通過異步復制，可保證99%的消息不丟，但是仍然會有極少量的消息可能丟失，通過同步雙寫技術(shù)可以避免單點，同步雙寫勢必會影響性能，適合對消息可靠性要求極高的場合，例如與Money相關(guān)的應(yīng)用。
rocketmq3.0版本支持同步雙寫

7、Low Latency Messaging（低消息延遲）

如果在消息沒有堆積的情況下，在消息到大broker后，立刻到達Consumer Rocketmq使用長輪詢Pull方式，可保證消息非常實時，消息實時性不低于Push

8、At Least One（至少一次）

每個消息必須投遞一次。RocketMq Consumer先pull消息到本地，消費完成后，才向服務(wù)器返回ack，如果沒有消費一定不回ack消息，所以Rocket MQ很好的支持此特性

9、Exactly Only One（只有一次）

1）發(fā)送消息階段，不允許發(fā)送重復的消息
2）消費消息階段，不允許消費重復的消息
要實現(xiàn)這兩點，在分布式系統(tǒng)環(huán)境下，不可避免要產(chǎn)生巨大的開銷，所以Rocketmq不保證此特性，要求在業(yè)務(wù)上進行去重，也就是要消費消息做到冪等。
雖然rocketmq不能嚴格保證不重復，但是正常情況下很少會出現(xiàn)重復推送、消費情況，只有網(wǎng)絡(luò)異常，Consumer啟停等異常情況下會出現(xiàn)消費重復。 此問題的本質(zhì)原因是網(wǎng)絡(luò)調(diào)用存在不確定性，即既不成功也不失敗的第三種狀態(tài)，所以才產(chǎn)生了消息重復性問題。

10、broker的buffer滿了怎么辦？

Rocketmq中沒有內(nèi)存buffer概念，rocketmq的隊列都是持久化磁盤，數(shù)據(jù)定期清除。
對于此問題解決思路，rocketmq與其他mq不同，rocketmq的內(nèi)buffer抽象成一個無限長度的隊列，不管有多少數(shù)據(jù)來都能裝的下，這個無限是有前提的，broker會定期刪除過期的數(shù)據(jù)。例如brokr只保存3天，那么這個buffer雖然長度無限，但是3天前的數(shù)據(jù)會被從隊尾刪除。

11、回溯消費

回溯消費是指consumer已經(jīng)消費成功的消息，由于業(yè)務(wù)上的需求需要重新消費。要支持此功能，broker再向consumer投遞成功消息后，消息仍然要保留，并且重新消費一般是按照時間維度。
RocketMQ支持按照時間回溯消費，時間維度精確到毫秒，可以向前回溯，也可以向后回溯。

12、消息堆積

消息中間件的主要功能是異步解耦，迓有個重要功能是擋住前端的數(shù)據(jù)洪峰，保證后端系統(tǒng)的穩(wěn)定性，這就要求消息中間件具有一定的消息堆積能力，消息堆積分以下兩種情況:
(1)消息堆積在內(nèi)存Buffer，一旦超過內(nèi)存 Buffer，可以根據(jù)一定的丟棄策略來丟棄消息，如 CORBA Notification 規(guī)范中描述。適合能容忍丟棄消息的業(yè)務(wù)，這種情況消息的堆積能力主要在于內(nèi)存 Buffer 大小，而且消息堆積后，性能下降不會太大，因為內(nèi)存中數(shù)據(jù)多少對于對外提供的訪問能力影響有限。
(2)消息堆積到持久化存儲系統(tǒng)中，例如DB，KV存儲，文件記錄形式。對于消息不能在內(nèi)存 Cache 命中時，要不可避免的訪問磁盤，會產(chǎn)生大量讀 IO，讀 IO 的吞吐量直接決定了消息堆積后的訪問能力。
評估消息堆積能力主要有以下四點:
(1). 消息能堆積多少條，多少字節(jié)?即消息的堆積容量。
(2). 消息堆積后，發(fā)消息的吞吐量大小，是否會受堆積影響?
(3). 消息堆積后，正常消費的Consumer是否會受影響?
(4). 消息堆積后，訪問堆積在磁盤的消息時，吞吏量有多大?

13、分布式事務(wù)

已知的幾個分布式事務(wù)規(guī)范，如：XA,JTA。其中XA規(guī)范被各大數(shù)據(jù)庫廠商廣泛支持。如：Orcal、Mysql等。
XA 是一個兩階段提交協(xié)議，該協(xié)議分為以下兩個階段： 第一階段：事務(wù)協(xié)調(diào)器要求每個涉及到事務(wù)的數(shù)據(jù)庫預提交(precommit)此操作，并反映是否可以提交.
第二階段：事務(wù)協(xié)調(diào)器要求每個數(shù)據(jù)庫提交數(shù)據(jù)。 Rocketmq實現(xiàn)事務(wù)的方式?jīng)]有通過kv存儲，而是通過offset方式來訪問消息。存在一個顯著缺陷，就是用過offset更改數(shù)據(jù)，會令系統(tǒng)的臟頁過多，需要特別的關(guān)注。

14、定時消息

定時消息是指消息發(fā)送到broker后，不能立刻被Conusmer消費，要到特定的時間點或者等待特定的時間后才能被消費。 Rocketmq支持定時消息，但是不自持任意時間精度，支持特定的level，例如定時5s，10s，1m等。

15、消息重試

Consumer消費消息失敗后，要提供一種重試機制，令消息再消費一次。 消費消息失敗通常認為有以下幾種情況：
1）由于消息本身原因，例如反序列化失敗，消息數(shù)據(jù)本身無法處理。這種錯誤通常需要跳過這條消息，再消費其他消息，而這條失敗的消息即使立刻重試消費，99%也不成功所以最好提供一種定時重試機制，即過10s后再重試
2）由于依賴的下游應(yīng)用服務(wù)不可用，例如：db連接不可用，外系網(wǎng)絡(luò)不可達等。遇到這種情況，即使跳過當前失敗的消息，消費其他消息同樣也會報錯。這種情況建議sleep 30秒再消費下一條消息，這樣減輕broker重試消息的壓力。

看完上述內(nèi)容，你們對rocketmq中專業(yè)術(shù)語、消息隊列需要解決的問題有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。