https://github.com/apache/rocketmq/tree/master/docs/cn
1 消息模型（Message Model）
RocketMQ主要由 Producer、Broker椰于、Consumer 三部分組成软免，其中Producer 負(fù)責(zé)生產(chǎn)消息凿将，Consumer 負(fù)責(zé)消費(fèi)消息隙赁，Broker 負(fù)責(zé)存儲消息爬骤。Broker 在實(shí)際部署過程中對應(yīng)一臺服務(wù)器幢竹，每個(gè) Broker 可以存儲多個(gè)Topic的消息榛臼，每個(gè)Topic的消息也可以分片存儲于不同的 Broker伊佃。Message Queue 用于存儲消息的物理地址，每個(gè)Topic中的消息地址存儲于多個(gè) Message Queue 中沛善。ConsumerGroup 由多個(gè)Consumer 實(shí)例構(gòu)成航揉。
2 消息生產(chǎn)者（Producer）
負(fù)責(zé)生產(chǎn)消息，一般由業(yè)務(wù)系統(tǒng)負(fù)責(zé)生產(chǎn)消息金刁。一個(gè)消息生產(chǎn)者會把業(yè)務(wù)應(yīng)用系統(tǒng)里產(chǎn)生的消息發(fā)送到broker服務(wù)器帅涂。RocketMQ提供多種發(fā)送方式，同步發(fā)送尤蛮、異步發(fā)送媳友、順序發(fā)送、單向發(fā)送产捞。同步和異步方式均需要Broker返回確認(rèn)信息醇锚，單向發(fā)送不需要。
3 消息消費(fèi)者（Consumer）
負(fù)責(zé)消費(fèi)消息坯临，一般是后臺系統(tǒng)負(fù)責(zé)異步消費(fèi)焊唬。一個(gè)消息消費(fèi)者會從Broker服務(wù)器拉取消息、并將其提供給應(yīng)用程序看靠。從用戶應(yīng)用的角度而言提供了兩種消費(fèi)形式：拉取式消費(fèi)赶促、推動式消費(fèi)。
4 主題（Topic）
表示一類消息的集合挟炬，每個(gè)主題包含若干條消息芳杏，每條消息只能屬于一個(gè)主題，是RocketMQ進(jìn)行消息訂閱的基本單位辟宗。
5 代理服務(wù)器（Broker Server）
消息中轉(zhuǎn)角色爵赵，負(fù)責(zé)存儲消息、轉(zhuǎn)發(fā)消息泊脐。代理服務(wù)器在RocketMQ系統(tǒng)中負(fù)責(zé)接收從生產(chǎn)者發(fā)送來的消息并存儲空幻、同時(shí)為消費(fèi)者的拉取請求作準(zhǔn)備。代理服務(wù)器也存儲消息相關(guān)的元數(shù)據(jù)容客，包括消費(fèi)者組秕铛、消費(fèi)進(jìn)度偏移和主題和隊(duì)列消息等。
6 名字服務(wù)（Name Server）
名稱服務(wù)充當(dāng)路由消息的提供者缩挑。生產(chǎn)者或消費(fèi)者能夠通過名字服務(wù)查找各主題相應(yīng)的Broker IP列表但两。多個(gè)Namesrv實(shí)例組成集群，但相互獨(dú)立供置，沒有信息交換谨湘。
7 拉取式消費(fèi)（Pull Consumer）
Consumer消費(fèi)的一種類型，應(yīng)用通常主動調(diào)用Consumer的拉消息方法從Broker服務(wù)器拉消息、主動權(quán)由應(yīng)用控制紧阔。一旦獲取了批量消息坊罢，應(yīng)用就會啟動消費(fèi)過程。
8 推動式消費(fèi)（Push Consumer）
Consumer消費(fèi)的一種類型擅耽，該模式下Broker收到數(shù)據(jù)后會主動推送給消費(fèi)端活孩，該消費(fèi)模式一般實(shí)時(shí)性較高。
9 生產(chǎn)者組（Producer Group）
同一類Producer的集合乖仇，這類Producer發(fā)送同一類消息且發(fā)送邏輯一致憾儒。如果發(fā)送的是事務(wù)消息且原始生產(chǎn)者在發(fā)送之后崩潰，則Broker服務(wù)器會聯(lián)系同一生產(chǎn)者組的其他生產(chǎn)者實(shí)例以提交或回溯消費(fèi)乃沙。
10 消費(fèi)者組（Consumer Group）
同一類Consumer的集合起趾，這類Consumer通常消費(fèi)同一類消息且消費(fèi)邏輯一致。消費(fèi)者組使得在消息消費(fèi)方面崔涂，實(shí)現(xiàn)負(fù)載均衡和容錯(cuò)的目標(biāo)變得非常容易阳掐。要注意的是，消費(fèi)者組的消費(fèi)者實(shí)例必須訂閱完全相同的Topic冷蚂。RocketMQ 支持兩種消息模式：集群消費(fèi)（Clustering）和廣播消費(fèi)（Broadcasting）缭保。
11 集群消費(fèi)（Clustering）
集群消費(fèi)模式下,相同Consumer Group的每個(gè)Consumer實(shí)例平均分?jǐn)傁ⅰ?/p>
12 廣播消費(fèi)（Broadcasting）
廣播消費(fèi)模式下，相同Consumer Group的每個(gè)Consumer實(shí)例都接收全量的消息蝙茶。
13 普通順序消息（Normal Ordered Message）
普通順序消費(fèi)模式下艺骂，消費(fèi)者通過同一個(gè)消息隊(duì)列（ Topic 分區(qū)，稱作 Message Queue） 收到的消息是有順序的隆夯，不同消息隊(duì)列收到的消息則可能是無順序的钳恕。
14 嚴(yán)格順序消息（Strictly Ordered Message）
嚴(yán)格順序消息模式下，消費(fèi)者收到的所有消息均是有順序的蹄衷。
15 消息（Message）
消息系統(tǒng)所傳輸信息的物理載體忧额，生產(chǎn)和消費(fèi)數(shù)據(jù)的最小單位，每條消息必須屬于一個(gè)主題愧口。RocketMQ中每個(gè)消息擁有唯一的Message ID睦番，且可以攜帶具有業(yè)務(wù)標(biāo)識的Key。系統(tǒng)提供了通過Message ID和Key查詢消息的功能耍属。
16 標(biāo)簽（Tag）
為消息設(shè)置的標(biāo)志托嚣，用于同一主題下區(qū)分不同類型的消息。來自同一業(yè)務(wù)單元的消息厚骗，可以根據(jù)不同業(yè)務(wù)目的在同一主題下設(shè)置不同標(biāo)簽示启。標(biāo)簽?zāi)軌蛴行У乇３执a的清晰度和連貫性，并優(yōu)化RocketMQ提供的查詢系統(tǒng)领舰。消費(fèi)者可以根據(jù)Tag實(shí)現(xiàn)對不同子主題的不同消費(fèi)邏輯夫嗓，實(shí)現(xiàn)更好的擴(kuò)展性迟螺。
特性(features)
1 訂閱與發(fā)布
消息的發(fā)布是指某個(gè)生產(chǎn)者向某個(gè)topic發(fā)送消息；消息的訂閱是指某個(gè)消費(fèi)者關(guān)注了某個(gè)topic中帶有某些tag的消息啤月，進(jìn)而從該topic消費(fèi)數(shù)據(jù)煮仇。
2 消息順序
消息有序指的是一類消息消費(fèi)時(shí)劳跃，能按照發(fā)送的順序來消費(fèi)谎仲。例如：一個(gè)訂單產(chǎn)生了三條消息分別是訂單創(chuàng)建、訂單付款刨仑、訂單完成郑诺。消費(fèi)時(shí)要按照這個(gè)順序消費(fèi)才能有意義，但是同時(shí)訂單之間是可以并行消費(fèi)的杉武。RocketMQ可以嚴(yán)格的保證消息有序辙诞。
順序消息分為全局順序消息與分區(qū)順序消息，全局順序是指某個(gè)Topic下的所有消息都要保證順序轻抱；部分順序消息只要保證每一組消息被順序消費(fèi)即可飞涂。
- 全局順序 對于指定的一個(gè) Topic，所有消息按照嚴(yán)格的先入先出（FIFO）的順序進(jìn)行發(fā)布和消費(fèi)祈搜。 適用場景：性能要求不高较店，所有的消息嚴(yán)格按照 FIFO 原則進(jìn)行消息發(fā)布和消費(fèi)的場景
- 分區(qū)順序 對于指定的一個(gè) Topic，所有消息根據(jù) sharding key 進(jìn)行區(qū)塊分區(qū)容燕。 同一個(gè)分區(qū)內(nèi)的消息按照嚴(yán)格的 FIFO 順序進(jìn)行發(fā)布和消費(fèi)梁呈。 Sharding key 是順序消息中用來區(qū)分不同分區(qū)的關(guān)鍵字段，和普通消息的 Key 是完全不同的概念蘸秘。 適用場景：性能要求高官卡，以 sharding key 作為分區(qū)字段，在同一個(gè)區(qū)塊中嚴(yán)格的按照 FIFO 原則進(jìn)行消息發(fā)布和消費(fèi)的場景醋虏。
3 消息過濾
RocketMQ的消費(fèi)者可以根據(jù)Tag進(jìn)行消息過濾寻咒，也支持自定義屬性過濾。消息過濾目前是在Broker端實(shí)現(xiàn)的颈嚼，優(yōu)點(diǎn)是減少了對于Consumer無用消息的網(wǎng)絡(luò)傳輸毛秘，缺點(diǎn)是增加了Broker的負(fù)擔(dān)、而且實(shí)現(xiàn)相對復(fù)雜粘舟。
4 消息可靠性
RocketMQ支持消息的高可靠熔脂，影響消息可靠性的幾種情況：
- Broker非正常關(guān)閉
- Broker異常Crash
- OS Crash
- 機(jī)器掉電，但是能立即恢復(fù)供電情況
- 機(jī)器無法開機(jī)（可能是cpu柑肴、主板霞揉、內(nèi)存等關(guān)鍵設(shè)備損壞）
- 磁盤設(shè)備損壞
1)、2)晰骑、3)适秩、4) 四種情況都屬于硬件資源可立即恢復(fù)情況绊序，RocketMQ在這四種情況下能保證消息不丟，或者丟失少量數(shù)據(jù)（依賴刷盤方式是同步還是異步）秽荞。
5)骤公、6)屬于單點(diǎn)故障，且無法恢復(fù)扬跋，一旦發(fā)生阶捆，在此單點(diǎn)上的消息全部丟失。RocketMQ在這兩種情況下钦听，通過異步復(fù)制洒试，可保證99%的消息不丟，但是仍然會有極少量的消息可能丟失朴上。通過同步雙寫技術(shù)可以完全避免單點(diǎn)垒棋，同步雙寫勢必會影響性能，適合對消息可靠性要求極高的場合痪宰，例如與Money相關(guān)的應(yīng)用叼架。注：RocketMQ從3.0版本開始支持同步雙寫。
5 至少一次
至少一次(At least Once)指每個(gè)消息必須投遞一次衣撬。Consumer先Pull消息到本地乖订，消費(fèi)完成后，才向服務(wù)器返回ack淮韭，如果沒有消費(fèi)一定不會ack消息垢粮，所以RocketMQ可以很好的支持此特性。
6 回溯消費(fèi)
回溯消費(fèi)是指Consumer已經(jīng)消費(fèi)成功的消息靠粪，由于業(yè)務(wù)上需求需要重新消費(fèi)蜡吧，要支持此功能，Broker在向Consumer投遞成功消息后占键，消息仍然需要保留昔善。并且重新消費(fèi)一般是按照時(shí)間維度，例如由于Consumer系統(tǒng)故障畔乙，恢復(fù)后需要重新消費(fèi)1小時(shí)前的數(shù)據(jù)君仆，那么Broker要提供一種機(jī)制，可以按照時(shí)間維度來回退消費(fèi)進(jìn)度牲距。RocketMQ支持按照時(shí)間回溯消費(fèi)返咱，時(shí)間維度精確到毫秒。
7 事務(wù)消息
RocketMQ事務(wù)消息（Transactional Message）是指應(yīng)用本地事務(wù)和發(fā)送消息操作可以被定義到全局事務(wù)中牍鞠，要么同時(shí)成功咖摹，要么同時(shí)失敗。RocketMQ的事務(wù)消息提供類似 X/Open XA 的分布事務(wù)功能难述，通過事務(wù)消息能達(dá)到分布式事務(wù)的最終一致萤晴。
8 定時(shí)消息
定時(shí)消息（延遲隊(duì)列）是指消息發(fā)送到broker后吐句，不會立即被消費(fèi)，等待特定時(shí)間投遞給真正的topic店读。 broker有配置項(xiàng)messageDelayLevel嗦枢，默認(rèn)值為“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”，18個(gè)level屯断∥穆玻可以配置自定義messageDelayLevel。注意裹纳，messageDelayLevel是broker的屬性择葡，不屬于某個(gè)topic紧武。發(fā)消息時(shí)剃氧，設(shè)置delayLevel等級即可：msg.setDelayLevel(level)。level有以下三種情況：
- level == 0阻星，消息為非延遲消息
- 1<=level<=maxLevel朋鞍，消息延遲特定時(shí)間，例如level==1妥箕，延遲1s
- level > maxLevel滥酥，則level== maxLevel，例如level==20畦幢，延遲2h
定時(shí)消息會暫存在名為SCHEDULE_TOPIC_XXXX的topic中坎吻，并根據(jù)delayTimeLevel存入特定的queue，queueId = delayTimeLevel – 1宇葱，即一個(gè)queue只存相同延遲的消息瘦真，保證具有相同發(fā)送延遲的消息能夠順序消費(fèi)。broker會調(diào)度地消費(fèi)SCHEDULE_TOPIC_XXXX黍瞧，將消息寫入真實(shí)的topic诸尽。
需要注意的是，定時(shí)消息會在第一次寫入和調(diào)度寫入真實(shí)topic時(shí)都會計(jì)數(shù)印颤，因此發(fā)送數(shù)量您机、tps都會變高。
9 消息重試
Consumer消費(fèi)消息失敗后年局，要提供一種重試機(jī)制际看，令消息再消費(fèi)一次。Consumer消費(fèi)消息失敗通呈阜瘢可以認(rèn)為有以下幾種情況：
- 由于消息本身的原因仲闽，例如反序列化失敗，消息數(shù)據(jù)本身無法處理（例如話費(fèi)充值兴喂，當(dāng)前消息的手機(jī)號被注銷蔼囊，無法充值）等焚志。這種錯(cuò)誤通常需要跳過這條消息，再消費(fèi)其它消息畏鼓，而這條失敗的消息即使立刻重試消費(fèi)酱酬，99%也不成功，所以最好提供一種定時(shí)重試機(jī)制云矫，即過10秒后再重試膳沽。
- 由于依賴的下游應(yīng)用服務(wù)不可用，例如db連接不可用让禀，外系統(tǒng)網(wǎng)絡(luò)不可達(dá)等挑社。遇到這種錯(cuò)誤，即使跳過當(dāng)前失敗的消息巡揍，消費(fèi)其他消息同樣也會報(bào)錯(cuò)痛阻。這種情況建議應(yīng)用sleep 30s，再消費(fèi)下一條消息腮敌，這樣可以減輕Broker重試消息的壓力阱当。
RocketMQ會為每個(gè)消費(fèi)組都設(shè)置一個(gè)Topic名稱為“%RETRY%+consumerGroup”的重試隊(duì)列（這里需要注意的是，這個(gè)Topic的重試隊(duì)列是針對消費(fèi)組糜工，而不是針對每個(gè)Topic設(shè)置的）弊添，用于暫時(shí)保存因?yàn)楦鞣N異常而導(dǎo)致Consumer端無法消費(fèi)的消息“颇荆考慮到異秤桶樱恢復(fù)起來需要一些時(shí)間，會為重試隊(duì)列設(shè)置多個(gè)重試級別刨裆，每個(gè)重試級別都有與之對應(yīng)的重新投遞延時(shí)澈圈，重試次數(shù)越多投遞延時(shí)就越大。RocketMQ對于重試消息的處理是先保存至Topic名稱為“SCHEDULE_TOPIC_XXXX”的延遲隊(duì)列中崔拥，后臺定時(shí)任務(wù)按照對應(yīng)的時(shí)間進(jìn)行Delay后重新保存至“%RETRY%+consumerGroup”的重試隊(duì)列中极舔。
10 消息重投
生產(chǎn)者在發(fā)送消息時(shí)，同步消息失敗會重投链瓦，異步消息有重試拆魏，oneway沒有任何保證。消息重投保證消息盡可能發(fā)送成功慈俯、不丟失渤刃，但可能會造成消息重復(fù)，消息重復(fù)在RocketMQ中是無法避免的問題贴膘。消息重復(fù)在一般情況下不會發(fā)生卖子，當(dāng)出現(xiàn)消息量大、網(wǎng)絡(luò)抖動刑峡，消息重復(fù)就會是大概率事件洋闽。另外玄柠，生產(chǎn)者主動重發(fā)、consumer負(fù)載變化也會導(dǎo)致重復(fù)消息诫舅。如下方法可以設(shè)置消息重試策略：
- retryTimesWhenSendFailed:同步發(fā)送失敗重投次數(shù)羽利，默認(rèn)為2，因此生產(chǎn)者會最多嘗試發(fā)送retryTimesWhenSendFailed + 1次刊懈。不會選擇上次失敗的broker这弧，嘗試向其他broker發(fā)送，最大程度保證消息不丟虚汛。超過重投次數(shù)匾浪，拋出異常，由客戶端保證消息不丟卷哩。當(dāng)出現(xiàn)RemotingException蛋辈、MQClientException和部分MQBrokerException時(shí)會重投。
- retryTimesWhenSendAsyncFailed:異步發(fā)送失敗重試次數(shù)殉疼，異步重試不會選擇其他broker梯浪，僅在同一個(gè)broker上做重試，不保證消息不丟瓢娜。
- retryAnotherBrokerWhenNotStoreOK:消息刷盤（主或備）超時(shí)或slave不可用（返回狀態(tài)非SEND_OK），是否嘗試發(fā)送到其他broker礼预，默認(rèn)false眠砾。十分重要消息可以開啟。
11 流量控制
生產(chǎn)者流控托酸，因?yàn)閎roker處理能力達(dá)到瓶頸褒颈；消費(fèi)者流控，因?yàn)橄M(fèi)能力達(dá)到瓶頸励堡。
生產(chǎn)者流控：
- commitLog文件被鎖時(shí)間超過osPageCacheBusyTimeOutMills時(shí)谷丸，參數(shù)默認(rèn)為1000ms，返回流控应结。
- 如果開啟transientStorePoolEnable == true刨疼，且broker為異步刷盤的主機(jī)，且transientStorePool中資源不足鹅龄，拒絕當(dāng)前send請求揩慕，返回流控。
- broker每隔10ms檢查send請求隊(duì)列頭部請求的等待時(shí)間扮休，如果超過waitTimeMillsInSendQueue迎卤，默認(rèn)200ms，拒絕當(dāng)前send請求玷坠，返回流控蜗搔。
- broker通過拒絕send 請求方式實(shí)現(xiàn)流量控制劲藐。
注意，生產(chǎn)者流控樟凄，不會嘗試消息重投瘩燥。
消費(fèi)者流控：
- 消費(fèi)者本地緩存消息數(shù)超過pullThresholdForQueue時(shí)，默認(rèn)1000不同。
- 消費(fèi)者本地緩存消息大小超過pullThresholdSizeForQueue時(shí)厉膀，默認(rèn)100MB。
- 消費(fèi)者本地緩存消息跨度超過consumeConcurrentlyMaxSpan時(shí)二拐，默認(rèn)2000服鹅。
消費(fèi)者流控的結(jié)果是降低拉取頻率。
12 死信隊(duì)列
死信隊(duì)列用于處理無法被正常消費(fèi)的消息百新。當(dāng)一條消息初次消費(fèi)失敗企软，消息隊(duì)列會自動進(jìn)行消息重試；達(dá)到最大重試次數(shù)后饭望，若消費(fèi)依然失敗仗哨，則表明消費(fèi)者在正常情況下無法正確地消費(fèi)該消息，此時(shí)铅辞，消息隊(duì)列 不會立刻將消息丟棄厌漂，而是將其發(fā)送到該消費(fèi)者對應(yīng)的特殊隊(duì)列中。
RocketMQ將這種正常情況下無法被消費(fèi)的消息稱為死信消息（Dead-Letter Message）斟珊，將存儲死信消息的特殊隊(duì)列稱為死信隊(duì)列（Dead-Letter Queue）苇倡。在RocketMQ中，可以通過使用console控制臺對死信隊(duì)列中的消息進(jìn)行重發(fā)來使得消費(fèi)者實(shí)例再次進(jìn)行消費(fèi)囤踩。
