一.RocketMQ模型的基本概念纬黎。
1 消息模型（Message Model）
RocketMQ主要由 Producer、Broker全跨、Consumer 三部分組成，其中Producer 負責生產(chǎn)消息当娱，Consumer 負責消費消息，Broker 負責存儲消息政溃。Broker 在實際部署過程中對應一臺服務器趾访，每個 Broker 可以存儲多個Topic的消息态秧，每個Topic的消息也可以分片存儲于不同的 Broker董虱。Message Queue 用于存儲消息的物理地址，每個Topic中的消息地址存儲于多個 Message Queue 中申鱼。ConsumerGroup 由多個Consumer 實例構成愤诱。
2 消息生產(chǎn)者（Producer）
負責生產(chǎn)消息，一般由業(yè)務系統(tǒng)負責生產(chǎn)消息捐友。一個消息生產(chǎn)者會把業(yè)務應用系統(tǒng)里產(chǎn)生的消息發(fā)送到broker服務器淫半。RocketMQ提供多種發(fā)送方式，同步發(fā)送匣砖、異步發(fā)送科吭、順序發(fā)送、單向發(fā)送猴鲫。同步和異步方式均需要Broker返回確認信息对人，單向發(fā)送不需要。
3 消息消費者（Consumer）
負責消費消息拂共，一般是后臺系統(tǒng)負責異步消費牺弄。一個消息消費者會從Broker服務器拉取消息、并將其提供給應用程序宜狐。從用戶應用的角度而言提供了兩種消費形式：拉取式消費势告、推動式消費。
4 主題（Topic）
表示一類消息的集合抚恒，每個主題包含若干條消息咱台，每條消息只能屬于一個主題，是RocketMQ進行消息訂閱的基本單位俭驮。
5 代理服務器（Broker Server）
消息中轉(zhuǎn)角色回溺，負責存儲消息、轉(zhuǎn)發(fā)消息表鳍。代理服務器在RocketMQ系統(tǒng)中負責接收從生產(chǎn)者發(fā)送來的消息并存儲馅而、同時為消費者的拉取請求作準備。代理服務器也存儲消息相關的元數(shù)據(jù)譬圣，包括消費者組瓮恭、消費進度偏移和主題和隊列消息等。
6 名字服務（Name Server）
名稱服務充當路由消息的提供者厘熟。生產(chǎn)者或消費者能夠通過名字服務查找各主題相應的Broker IP列表屯蹦。多個Namesrv實例組成集群维哈，但相互獨立，沒有信息交換登澜。
7 拉取式消費（Pull Consumer）
Consumer消費的一種類型阔挠，應用通常主動調(diào)用Consumer的拉消息方法從Broker服務器拉消息、主動權由應用控制脑蠕。一旦獲取了批量消息购撼，應用就會啟動消費過程。
8 推動式消費（Push Consumer）
Consumer消費的一種類型谴仙，該模式下Broker收到數(shù)據(jù)后會主動推送給消費端迂求，該消費模式一般實時性較高。
9 生產(chǎn)者組（Producer Group）
同一類Producer的集合晃跺，這類Producer發(fā)送同一類消息且發(fā)送邏輯一致揩局。如果發(fā)送的是事務消息且原始生產(chǎn)者在發(fā)送之后崩潰，則Broker服務器會聯(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 消息（Message）
消息系統(tǒng)所傳輸信息的物理載體走芋，生產(chǎn)和消費數(shù)據(jù)的最小單位，每條消息必須屬于一個主題潘鲫。RocketMQ中每個消息擁有唯一的Message ID翁逞，且可以攜帶具有業(yè)務標識的Key。系統(tǒng)提供了通過Message ID和Key查詢消息的功能溉仑。
16 標簽（Tag）
為消息設置的標志挖函，用于同一主題下區(qū)分不同類型的消息浊竟。來自同一業(yè)務單元的消息津畸，可以根據(jù)不同業(yè)務目的在同一主題下設置不同標簽必怜。標簽能夠有效地保持代碼的清晰度和連貫性肉拓，并優(yōu)化RocketMQ提供的查詢系統(tǒng)。消費者可以根據(jù)Tag實現(xiàn)對不同子主題的不同消費邏輯梳庆，實現(xiàn)更好的擴展性。
RocketMQ特性(features)
1 訂閱與發(fā)布
消息的發(fā)布是指某個生產(chǎn)者向某個topic發(fā)送消息丧肴；消息的訂閱是指某個消費者關注了某個topic中帶有某些tag的消息残揉，進而從該topic消費數(shù)據(jù)胧后。
2 消息順序
消息有序指的是一類消息消費時，能按照發(fā)送的順序來消費抱环。例如：一個訂單產(chǎn)生了三條消息分別是訂單創(chuàng)建镇草、訂單付款、訂單完成梯啤。消費時要按照這個順序消費才能有意義因宇，但是同時訂單之間是可以并行消費的。RocketMQ可以嚴格的保證消息有序察滑。
順序消息分為全局順序消息與分區(qū)順序消息贺辰，全局順序是指某個Topic下的所有消息都要保證順序；部分順序消息只要保證每一組消息被順序消費即可饲化。
- 全局順序 對于指定的一個 Topic吃靠，所有消息按照嚴格的先入先出（FIFO）的順序進行發(fā)布和消費。 適用場景：性能要求不高捺球，所有的消息嚴格按照 FIFO 原則進行消息發(fā)布和消費的場景
- 分區(qū)順序 對于指定的一個 Topic，所有消息根據(jù) sharding key 進行區(qū)塊分區(qū)裂逐。 同一個分區(qū)內(nèi)的消息按照嚴格的 FIFO 順序進行發(fā)布和消費泣栈。 Sharding key 是順序消息中用來區(qū)分不同分區(qū)的關鍵字段，和普通消息的 Key 是完全不同的概念掺涛。 適用場景：性能要求高疼进，以 sharding key 作為分區(qū)字段，在同一個區(qū)塊中嚴格的按照 FIFO 原則進行消息發(fā)布和消費的場景拣帽。
3 消息過濾
RocketMQ的消費者可以根據(jù)Tag進行消息過濾嚼锄，也支持自定義屬性過濾。消息過濾目前是在Broker端實現(xiàn)的拧粪，優(yōu)點是減少了對于Consumer無用消息的網(wǎng)絡傳輸沧侥，缺點是增加了Broker的負擔正什、而且實現(xiàn)相對復雜。
4 消息可靠性
RocketMQ支持消息的高可靠斯棒，影響消息可靠性的幾種情況：
- Broker非正常關閉
- Broker異常Crash
- OS Crash
- 機器掉電主经，但是能立即恢復供電情況
- 機器無法開機（可能是cpu、主板穗酥、內(nèi)存等關鍵設備損壞）
- 磁盤設備損壞
1)、2)骏啰、3)抽高、4) 四種情況都屬于硬件資源可立即恢復情況，RocketMQ在這四種情況下能保證消息不丟翘骂，或者丟失少量數(shù)據(jù)（依賴刷盤方式是同步還是異步）碳竟。
5)、6)屬于單點故障莹桅，且無法恢復统翩，一旦發(fā)生，在此單點上的消息全部丟失。RocketMQ在這兩種情況下呜师，通過異步復制懈费，可保證99%的消息不丟有梆，但是仍然會有極少量的消息可能丟失乎串。通過同步雙寫技術可以完全避免單點荸恕，同步雙寫勢必會影響性能，適合對消息可靠性要求極高的場合扁藕，例如與Money相關的應用亿柑。注：RocketMQ從3.0版本開始支持同步雙寫。
5 至少一次
至少一次(At least Once)指每個消息必須投遞一次疟游。Consumer先Pull消息到本地，消費完成后役耕，才向服務器返回ack聪廉，如果沒有消費一定不會ack消息，所以RocketMQ可以很好的支持此特性框全。
6 回溯消費
回溯消費是指Consumer已經(jīng)消費成功的消息干签，由于業(yè)務上需求需要重新消費容劳，要支持此功能，Broker在向Consumer投遞成功消息后蚜印，消息仍然需要保留留量。并且重新消費一般是按照時間維度，例如由于Consumer系統(tǒng)故障忆绰，恢復后需要重新消費1小時前的數(shù)據(jù)可岂，那么Broker要提供一種機制缕粹，可以按照時間維度來回退消費進度。RocketMQ支持按照時間回溯消費峰锁，時間維度精確到毫秒双戳。
7 事務消息
RocketMQ事務消息（Transactional Message）是指應用本地事務和發(fā)送消息操作可以被定義到全局事務中，要么同時成功魄衅，要么同時失敗晃虫。RocketMQ的事務消息提供類似 X/Open XA 的分布事務功能，通過事務消息能達到分布式事務的最終一致扛吞。
8 定時消息
定時消息（延遲隊列）是指消息發(fā)送到broker后荆责，不會立即被消費，等待特定時間投遞給真正的topic做院。 broker有配置項messageDelayLevel键耕，默認值為“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”，18個level屈雄∨锬叮可以配置自定義messageDelayLevel。注意，messageDelayLevel是broker的屬性瘸彤，不屬于某個topic笛钝。發(fā)消息時，設置delayLevel等級即可：msg.setDelayLevel(level)结榄。level有以下三種情況：
- level == 0囤捻，消息為非延遲消息
- 1<=level<=maxLevel，消息延遲特定時間视哑，例如level==1挡毅，延遲1s
- level > maxLevel，則level== maxLevel段磨，例如level==20耗绿，延遲2h
定時消息會暫存在名為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消費消息失敗通扯鞴粒可以認為有以下幾種情況：
- 由于消息本身的原因，例如反序列化失敗里伯，消息數(shù)據(jù)本身無法處理（例如話費充值渤闷，當前消息的手機號被注銷飒箭，無法充值）等。這種錯誤通常需要跳過這條消息肩碟，再消費其它消息凸椿，而這條失敗的消息即使立刻重試消費脑漫，99%也不成功，所以最好提供一種定時重試機制吨拍，即過10秒后再重試网杆。
- 由于依賴的下游應用服務不可用跛璧，例如db連接不可用新啼，外系統(tǒng)網(wǎng)絡不可達等燥撞。遇到這種錯誤迷帜，即使跳過當前失敗的消息戏锹，消費其他消息同樣也會報錯火诸。這種情況建議應用sleep 30s，再消費下一條消息奈搜，這樣可以減輕Broker重試消息的壓力馋吗。
RocketMQ會為每個消費組都設置一個Topic名稱為“%RETRY%+consumerGroup”的重試隊列（這里需要注意的是秋秤，這個Topic的重試隊列是針對消費組灼卢，而不是針對每個Topic設置的），用于暫時保存因為各種異常而導致Consumer端無法消費的消息蛇摸〔忧桑考慮到異晨倥海恢復起來需要一些時間，會為重試隊列設置多個重試級別敬辣，每個重試級別都有與之對應的重新投遞延時零院，重試次數(shù)越多投遞延時就越大。RocketMQ對于重試消息的處理是先保存至Topic名稱為“SCHEDULE_TOPIC_XXXX”的延遲隊列中撰茎，后臺定時任務按照對應的時間進行Delay后重新保存至“%RETRY%+consumerGroup”的重試隊列中打洼。
10 消息重投
生產(chǎn)者在發(fā)送消息時，同步消息失敗會重投僻弹，異步消息有重試他嚷，oneway沒有任何保證爸舒。消息重投保證消息盡可能發(fā)送成功、不丟失鹊奖，但可能會造成消息重復涂炎，消息重復在RocketMQ中是無法避免的問題唱捣。消息重復在一般情況下不會發(fā)生，當出現(xiàn)消息量大赂毯、網(wǎng)絡抖動党涕，消息重復就會是大概率事件巡社。另外晌该，生產(chǎn)者主動重發(fā)、consumer負載變化也會導致重復消息燕耿。如下方法可以設置消息重試策略：
- retryTimesWhenSendFailed:同步發(fā)送失敗重投次數(shù)缸棵，默認為2，因此生產(chǎn)者會最多嘗試發(fā)送retryTimesWhenSendFailed + 1次。不會選擇上次失敗的broker踏志，嘗試向其他broker發(fā)送胀瞪，最大程度保證消息不丟凄诞。超過重投次數(shù)，拋出異常伪朽，由客戶端保證消息不丟烈涮。當出現(xiàn)RemotingException窖剑、MQClientException和部分MQBrokerException時會重投讶舰。
- retryTimesWhenSendAsyncFailed:異步發(fā)送失敗重試次數(shù)跳昼，異步重試不會選擇其他broker援所，僅在同一個broker上做重試住拭，不保證消息不丟滔岳。
- retryAnotherBrokerWhenNotStoreOK:消息刷盤（主或備）超時或slave不可用（返回狀態(tài)非SEND_OK），是否嘗試發(fā)送到其他broker摊求，默認false室叉。十分重要消息可以開啟。
11 流量控制
生產(chǎn)者流控野来，因為broker處理能力達到瓶頸曼氛；消費者流控令野，因為消費能力達到瓶頸气破。
生產(chǎn)者流控：
- commitLog文件被鎖時間超過osPageCacheBusyTimeOutMills時，參數(shù)默認為1000ms狗超，返回流控努咐。
- 如果開啟transientStorePoolEnable == true殴胧，且broker為異步刷盤的主機团滥，且transientStorePool中資源不足灸姊，拒絕當前send請求，返回流控碗誉。
- broker每隔10ms檢查send請求隊列頭部請求的等待時間哮缺，如果超過waitTimeMillsInSendQueue甲喝，默認200ms尝苇，拒絕當前send請求，返回流控。
- broker通過拒絕send 請求方式實現(xiàn)流量控制糠溜。
注意淳玩，生產(chǎn)者流控，不會嘗試消息重投诵冒。
消費者流控：
- 消費者本地緩存消息數(shù)超過pullThresholdForQueue時凯肋，默認1000。
- 消費者本地緩存消息大小超過pullThresholdSizeForQueue時汽馋，默認100MB。
- 消費者本地緩存消息跨度超過consumeConcurrentlyMaxSpan時豹芯，默認2000。
消費者流控的結果是降低拉取頻率驱敲。
12 死信隊列
死信隊列用于處理無法被正常消費的消息铁蹈。當一條消息初次消費失敗，消息隊列會自動進行消息重試众眨；達到最大重試次數(shù)后握牧，若消費依然失敗，則表明消費者在正常情況下無法正確地消費該消息娩梨，此時沿腰，消息隊列 不會立刻將消息丟棄，而是將其發(fā)送到該消費者對應的特殊隊列中狈定。
RocketMQ將這種正常情況下無法被消費的消息稱為死信消息（Dead-Letter Message）颂龙，將存儲死信消息的特殊隊列稱為死信隊列（Dead-Letter Queue）。在RocketMQ中纽什，可以通過使用console控制臺對死信隊列中的消息進行重發(fā)來使得消費者實例再次進行消費措嵌。
