RocketMQ使用教程相關(guān)系列 目錄 RocketMQ的基本概念模型1 消息模型（Message Model）RocketMQ主要由 Producer,、Broker、Consumer 三部分組成，其中Producer 負責(zé)生產(chǎn)消息，Consumer 負責(zé)消費消息，Broker 負責(zé)存儲消息,。Broker 在實際部署過程中對應(yīng)一臺服務(wù)器，每個 Broker 可以存儲多個Topic的消息，每個Topic的消息也可以分片存儲于不同的 Broker,。Message Queue 用于存儲消息的物理地址，每個Topic中的消息地址存儲于多個 Message Queue 中。ConsumerGroup 由多個Consumer 實例構(gòu)成,。 2 消息生產(chǎn)者（Producer）負責(zé)生產(chǎn)消息，一般由業(yè)務(wù)系統(tǒng)負責(zé)生產(chǎn)消息,。一個消息生產(chǎn)者會把業(yè)務(wù)應(yīng)用系統(tǒng)里產(chǎn)生的消息發(fā)送到broker服務(wù)器。RocketMQ提供多種發(fā)送方式，同步發(fā)送,、異步發(fā)送,、順序發(fā)送、單向發(fā)送,。同步和異步方式均需要Broker返回確認信息，單向發(fā)送不需要,。 3 消息消費者（Consumer）負責(zé)消費消息，一般是后臺系統(tǒng)負責(zé)異步消費,。一個消息消費者會從Broker服務(wù)器拉取消息、并將其提供給應(yīng)用程序,。從用戶應(yīng)用的角度而言提供了兩種消費形式：拉取式消費,、推動式消費。 4 主題（Topic）表示一類消息的集合，每個主題包含若干條消息，每條消息只能屬于一個主題，是RocketMQ進行消息訂閱的基本單位,。 5 代理服務(wù)器（Broker Server）消息中轉(zhuǎn)角色，負責(zé)存儲消息,、轉(zhuǎn)發(fā)消息。代理服務(wù)器在RocketMQ系統(tǒng)中負責(zé)接收從生產(chǎn)者發(fā)送來的消息并存儲,、同時為消費者的拉取請求作準備,。代理服務(wù)器也存儲消息相關(guān)的元數(shù)據(jù)，包括消費者組、消費進度偏移和主題和隊列消息等,。 6 名字服務(wù)（Name Server）名稱服務(wù)充當路由消息的提供者,。生產(chǎn)者或消費者能夠通過名字服務(wù)查找各主題相應(yīng)的Broker IP列表。多個Namesrv實例組成集群，但相互獨立，沒有信息交換,。 7 拉取式消費（Pull Consumer）Consumer消費的一種類型，應(yīng)用通常主動調(diào)用Consumer的拉消息方法從Broker服務(wù)器拉消息,、主動權(quán)由應(yīng)用控制。一旦獲取了批量消息，應(yīng)用就會啟動消費過程,。 8 推動式消費（Push Consumer）Consumer消費的一種類型，該模式下Broker收到數(shù)據(jù)后會主動推送給消費端，該消費模式一般實時性較高,。 9 生產(chǎn)者組（Producer Group）同一類Producer的集合，這類Producer發(fā)送同一類消息且發(fā)送邏輯一致。如果發(fā)送的是事物消息且原始生產(chǎn)者在發(fā)送之后崩潰，則Broker服務(wù)器會聯(lián)系同一生產(chǎn)者組的其他生產(chǎn)者實例以提交或回溯消費,。 10 消費者組（Consumer Group）同一類Consumer的集合，這類Consumer通常消費同一類消息且消費邏輯一致,。消費者組使得在消息消費方面，實現(xiàn)負載均衡和容錯的目標變得非常容易。要注意的是，消費者組的消費者實例必須訂閱完全相同的Topic,。RocketMQ 支持兩種消息模式：集群消費（Clustering）和廣播消費（Broadcasting）,。 11 集群消費（Clustering）集群消費模式下,相同Consumer Group的每個Consumer實例平均分攤消息。 12 廣播消費（Broadcasting）廣播消費模式下，相同Consumer Group的每個Consumer實例都接收全量的消息,。 13 普通順序消息（Normal Ordered Message）普通順序消費模式下，消費者通過同一個消費隊列收到的消息是有順序的，不同消息隊列收到的消息則可能是無順序的,。 14 嚴格順序消息（Strictly Ordered Message）嚴格順序消息模式下，消費者收到的所有消息均是有順序的。 15 代理服務(wù)器（Broker Server）消息中轉(zhuǎn)角色，負責(zé)存儲消息,、轉(zhuǎn)發(fā)消息,。代理服務(wù)器在RocketMQ系統(tǒng)中負責(zé)接收從生產(chǎn)者發(fā)送來的消息并存儲、同時為消費者的拉取請求作準備,。代理服務(wù)器也存儲消息相關(guān)的元數(shù)據(jù)，包括消費者組,、消費進度偏移和主題和隊列消息等。 16 消息（Message）消息系統(tǒng)所傳輸信息的物理載體，生產(chǎn)和消費數(shù)據(jù)的最小單位，每條消息必須屬于一個主題,。RocketMQ中每個消息擁有唯一的Message ID，且可以攜帶具有業(yè)務(wù)標識的Key,。系統(tǒng)提供了通過Message ID和Key查詢消息的功能。 17 標簽（Tag）為消息設(shè)置的標志，用于同一主題下區(qū)分不同類型的消息,。來自同一業(yè)務(wù)單元的消息，可以根據(jù)不同業(yè)務(wù)目的在同一主題下設(shè)置不同標簽,。標簽?zāi)軌蛴行У乇３执a的清晰度和連貫性，并優(yōu)化RocketMQ提供的查詢系統(tǒng),。消費者可以根據(jù)Tag實現(xiàn)對不同子主題的不同消費邏輯，實現(xiàn)更好的擴展性。 RocketMQ實現(xiàn)的功能特性1 訂閱與發(fā)布消息的發(fā)布是指某個生產(chǎn)者向某個topic發(fā)送消息；消息的訂閱是指某個消費者關(guān)注了某個topic中帶有某些tag的消息，進而從該topic消費數(shù)據(jù),。 2 消息順序消息有序指的是一類消息消費時，能按照發(fā)送的順序來消費,。例如：一個訂單產(chǎn)生了三條消息分別是訂單創(chuàng)建、訂單付款,、訂單完成,。消費時要按照這個順序消費才能有意義，但是同時訂單之間是可以并行消費的。RocketMQ可以嚴格的保證消息有序,。 順序消息分為全局順序消息與分區(qū)順序消息，全局順序是指某個Topic下的所有消息都要保證順序；部分順序消息只要保證每一組消息被順序消費即可,。
3 消息過濾RocketMQ的消費者可以根據(jù)Tag進行消息過濾，也支持自定義屬性過濾。消息過濾目前是在Broker端實現(xiàn)的，優(yōu)點是減少了對于Consumer無用消息的網(wǎng)絡(luò)傳輸，缺點是增加了Broker的負擔(dān),、而且實現(xiàn)相對復(fù)雜,。 4 消息可靠性RocketMQ支持消息的高可靠，影響消息可靠性的幾種情況：
1),、2)、3),、4) 四種情況都屬于硬件資源可立即恢復(fù)情況，RocketMQ在這四種情況下能保證消息不丟，或者丟失少量數(shù)據(jù)（依賴刷盤方式是同步還是異步）,。 5)、6)屬于單點故障，且無法恢復(fù)，一旦發(fā)生，在此單點上的消息全部丟失,。RocketMQ在這兩種情況下，通過異步復(fù)制，可保證99%的消息不丟，但是仍然會有極少量的消息可能丟失,。通過同步雙寫技術(shù)可以完全避免單點，同步雙寫勢必會影響性能，適合對消息可靠性要求極高的場合，例如與Money相關(guān)的應(yīng)用。注：RocketMQ從3.0版本開始支持同步雙寫,。 5 至少一次至少一次(At least Once)指每個消息必須投遞一次,。Consumer先Pull消息到本地，消費完成后，才向服務(wù)器返回ack，如果沒有消費一定不會ack消息，所以RocketMQ可以很好的支持此特性。 6 回溯消費回溯消費是指Consumer已經(jīng)消費成功的消息，由于業(yè)務(wù)上需求需要重新消費，要支持此功能，Broker在向Consumer投遞成功消息后，消息仍然需要保留,。并且重新消費一般是按照時間維度，例如由于Consumer系統(tǒng)故障，恢復(fù)后需要重新消費1小時前的數(shù)據(jù)，那么Broker要提供一種機制，可以按照時間維度來回退消費進度,。RocketMQ支持按照時間回溯消費，時間維度精確到毫秒。 7 事務(wù)消息RocketMQ事務(wù)消息（Transactional Message）是指應(yīng)用本地事務(wù)和發(fā)送消息操作可以被定義到全局事務(wù)中，要么同時成功，要么同時失敗,。RocketMQ的事務(wù)消息提供類似 X/Open XA 的分布事務(wù)功能，通過事務(wù)消息能達到分布式事務(wù)的最終一致,。 8 定時消息定時消息（延遲隊列）是指消息發(fā)送到broker后，不會立即被消費，等待特定時間投遞給真正的topic。
定時消息會暫存在名為SCHEDULE_TOPIC_XXXX的topic中，并根據(jù)delayTimeLevel存入特定的queue，queueId = delayTimeLevel – 1，即一個queue只存相同延遲的消息，保證具有相同發(fā)送延遲的消息能夠順序消費,。broker會調(diào)度地消費SCHEDULE_TOPIC_XXXX，將消息寫入真實的topic。 需要注意的是，定時消息會在第一次寫入和調(diào)度寫入真實topic時都會計數(shù)，因此發(fā)送數(shù)量,、tps都會變高,。 9 消息重試Consumer消費消息失敗后，要提供一種重試機制，令消息再消費一次。Consumer消費消息失敗通?？梢哉J為有以下幾種情況：
RocketMQ會為每個消費組都設(shè)置一個Topic名稱為“%RETRY%+consumerGroup”的重試隊列（這里需要注意的是，這個Topic的重試隊列是針對消費組，而不是針對每個Topic設(shè)置的），用于暫時保存因為各種異常而導(dǎo)致Consumer端無法消費的消息,?？紤]到異常恢復(fù)起來需要一些時間，會為重試隊列設(shè)置多個重試級別，每個重試級別都有與之對應(yīng)的重新投遞延時，重試次數(shù)越多投遞延時就越大,。RocketMQ對于重試消息的處理是先保存至Topic名稱為“SCHEDULE_TOPIC_XXXX”的延遲隊列中，后臺定時任務(wù)按照對應(yīng)的時間進行Delay后重新保存至“%RETRY%+consumerGroup”的重試隊列中,。 10 消息重投生產(chǎn)者在發(fā)送消息時，同步消息失敗會重投，異步消息有重試，oneway沒有任何保證。消息重投保證消息盡可能發(fā)送成功,、不丟失，但可能會造成消息重復(fù)，消息重復(fù)在RocketMQ中是無法避免的問題,。消息重復(fù)在一般情況下不會發(fā)生，當出現(xiàn)消息量大、網(wǎng)絡(luò)抖動，消息重復(fù)就會是大概率事件,。另外，生產(chǎn)者主動重發(fā),、consumer負載變化也會導(dǎo)致重復(fù)消息。如下方法可以設(shè)置消息重試策略：
11 流量控制生產(chǎn)者流控，因為broker處理能力達到瓶頸；消費者流控，因為消費能力達到瓶頸。 生產(chǎn)者流控：
注意，生產(chǎn)者流控，不會嘗試消息重投,。 消費者流控：
消費者流控的結(jié)果是降低拉取頻率,。 12 死信隊列死信隊列用于處理無法被正常消費的消息。當一條消息初次消費失敗，消息隊列會自動進行消息重試；達到最大重試次數(shù)后，若消費依然失敗，則表明消費者在正常情況下無法正確地消費該消息，此時，消息隊列 不會立刻將消息丟棄，而是將其發(fā)送到該消費者對應(yīng)的特殊隊列中,。 RocketMQ將這種正常情況下無法被消費的消息稱為死信消息（Dead-Letter Message），將存儲死信消息的特殊隊列稱為死信隊列（Dead-Letter Queue）,。在RocketMQ中，可以通過使用console控制臺對死信隊列中的消息進行重發(fā)來使得消費者實例再次進行消費。 |
|
|
