rocketmq中專業術語、消息隊列需要解決的問題

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

專業術語：

• Producer： 消息生產者，負責產生消息，一般由業務系統負責產生消息

• Consumer： 消息消費者，負責消費消息，一般是后臺系統負責異步消費

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

• Pull Consumer：
  Consumer的一種，通常主動調用Consumer的拉消息方法從broker拉消息，主動權由應用控制

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

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

• Broker：
  消息中轉角色，負責存儲消息，轉發消息，一般也稱為Server。在JMS規范中稱為Provider

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

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

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

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

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

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

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

1、Publish/Subscribe

發布訂閱消息是消息中間件的最基本的功能，也是相對于傳統的RPC而言

2、Message Priority（消息優先級）

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

3、Message Order（消息順序）

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

4、Message Filter

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

5、Message Persistence(消息持久化)

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

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

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

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

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

8、At Least One（至少一次）

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

9、Exactly Only One（只有一次）

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

10、broker的buffer滿了怎么辦？

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

11、回溯消費

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

12、消息堆積

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

13、分布式事務

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

14、定時消息

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

15、消息重試

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

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