基本概念
topic：消息主題风钻，通過 Topic 對不同的業(yè)務(wù)消息進(jìn)行分類。
tag：消息標(biāo)簽，用來進(jìn)一步區(qū)分某個(gè) Topic 下的消息分類绍赛，消息從生產(chǎn)者發(fā)出即帶上的屬性蔓纠。
keys:代表這條消息的業(yè)務(wù)關(guān)鍵詞
body:表示消息的存儲內(nèi)容
順序消息
對于一個(gè)指定的Topic，消息嚴(yán)格按照先進(jìn)先出（FIFO）的原則進(jìn)行消息發(fā)布和消費(fèi)吗蚌，即先發(fā)布的消息先消費(fèi)腿倚，后發(fā)布的消息后消費(fèi)。
RocketMQ 消息的順序性分為兩部分蚯妇，生產(chǎn)順序性和消費(fèi)順序性敷燎。只有同時(shí)滿足了生產(chǎn)順序性和消費(fèi)順序性才能達(dá)到上述的FIFO效果。
生產(chǎn)順序性： RocketMQ 通過生產(chǎn)者和服務(wù)端的協(xié)議保障單個(gè)生產(chǎn)者串行地發(fā)送消息箩言，并按序存儲和持久化硬贯。如需保證消息生產(chǎn)的順序性，則必須滿足以下條件：
單一生產(chǎn)者： 消息生產(chǎn)的順序性僅支持單一生產(chǎn)者陨收，不同生產(chǎn)者分布在不同的系統(tǒng)饭豹，即使設(shè)置相同的分區(qū)鍵，不同生產(chǎn)者之間產(chǎn)生的消息也無法判定其先后順序务漩。
串行發(fā)送：生產(chǎn)者客戶端支持多線程安全訪問拄衰，但如果生產(chǎn)者使用多線程并行發(fā)送，則不同線程間產(chǎn)生的消息將無法判定其先后順序饵骨。
例如創(chuàng)建訂單的場景翘悉，需要保證同一個(gè)訂單的生成、付款和發(fā)貨宏悦，這三個(gè)操作被順序執(zhí)行镐确。如果是普通消息，訂單A的消息可能會被輪詢發(fā)送到不同的隊(duì)列中饼煞，不同隊(duì)列的消息將無法保持順序源葫，而順序消息發(fā)送時(shí)將ShardingKey相同（同一訂單號）的消息序路由到一個(gè)邏輯隊(duì)列中。
延遲消息
當(dāng)消息寫入到Broker后砖瞧，不能立刻被消費(fèi)者消費(fèi)息堂，需要等待指定的時(shí)長后才可被消費(fèi)處理的消息
Rocket MQ延時(shí)消息的延遲時(shí)長不支持隨意時(shí)長的延遲，是通過特定的延遲等級來指定的块促。默認(rèn)支持18個(gè)等級的延遲消息
例如指定的延時(shí)等級為2荣堰，則表示延遲時(shí)長為5s，延時(shí)等級為3竭翠，則表示延遲時(shí)長為10s振坚，即延遲等級是從1開始計(jì)數(shù)的。
延遲消息使用場景
- 在電商交易系統(tǒng)中斋扰，像淘寶渡八、京東啃洋，我們提交了一個(gè)訂單之后，在支付時(shí)都會
提示屎鳍，需要在指定時(shí)間內(nèi)（例如30分鐘）完成支付宏娄，否則訂單將被取消的消息，
實(shí)際上這個(gè)超時(shí)未支付功能就可以使用延時(shí)消息來實(shí)現(xiàn)逮壁。在下單成功之后孵坚，就
發(fā)送一個(gè)延時(shí)消息，然后指定消息的延時(shí)時(shí)間為30分鐘窥淆，這條消息將會在30
分鐘后投遞給后臺業(yè)務(wù)系統(tǒng)(Consumer),此時(shí)才能被消費(fèi)者進(jìn)行消費(fèi)卖宠，消
費(fèi)消息的時(shí)候會再去檢查這個(gè)訂單的狀態(tài)，確認(rèn)下是否支付成功祖乳，如果支付成
功逗堵，則忽略不處理；如果訂單還是未支付眷昆，則進(jìn)行取消訂單蜒秤、釋放庫存等操
作；
- 比如B站視頻投稿經(jīng)常會發(fā)起一些活動亚斋，Up主在活動期間可以按照活動規(guī)則投
稿視頻作媚，在活動時(shí)間截止后，后臺根據(jù)Up主完成任務(wù)的情況以及結(jié)合投稿視頻
的播放量等進(jìn)行判定帅刊，然后派發(fā)對應(yīng)的獎勵纸泡。這種場景我們也可以采用延時(shí)消
息來實(shí)現(xiàn)，即在發(fā)起活動后赖瞒，同時(shí)發(fā)送一條延時(shí)消息女揭，延時(shí)時(shí)間設(shè)置為本次活
動周期的時(shí)間。當(dāng)活動結(jié)束后栏饮，這條延時(shí)消息剛好可以被消費(fèi)者進(jìn)行消費(fèi)吧兔，這
樣就可以消費(fèi)消息然后執(zhí)行一系列的邏輯處理。
RocketMq中提供兩種消費(fèi)模式：集群模式和廣播模式
集群模式表示同一個(gè)消息會被同一個(gè)消費(fèi)組中的消費(fèi)者消費(fèi)一次袍嬉，消息被負(fù)載均衡分配到同一個(gè)消費(fèi)者上的多個(gè)實(shí)例上境蔼。
廣播模式表示同一個(gè)消息會推送到集群里面所有的消費(fèi)者，保證消息至少被每個(gè)消費(fèi)者消費(fèi)一次伺通。
并發(fā)消費(fèi)和順序消費(fèi)
在并發(fā)消費(fèi)中箍土，可能會有多個(gè)線程同時(shí)消費(fèi)一個(gè)隊(duì)列的消息，因此即使發(fā)送端通過發(fā)送順序消息保證消息在同一個(gè)隊(duì)列中按照FIFO的順序罐监，也無法保證消息實(shí)際被順序消費(fèi)吴藻。實(shí)現(xiàn)了MessageListenerConcurrently接口
順序消費(fèi)是指消息按照一定的順序進(jìn)行處理，同一個(gè)消息隊(duì)列上的消息按照發(fā)送順序和消費(fèi)順序進(jìn)行處理弓柱。
順序消費(fèi)通常需要保證同一消息隊(duì)列上只有一個(gè)消費(fèi)者實(shí)例處理消息沟堡，以確保消息的順序性疮鲫。實(shí)現(xiàn)了MessageListenerOrderly接口
其他
- NameServer：NameServer 是一個(gè)非常簡單的 Topic 路由注冊中心，是一個(gè)無狀態(tài)的服務(wù)器弦叶，角色類似于 Kafka 使用的 Zookeeper，但比 Zookeeper 更輕量妇多。支持 Broker 的動態(tài)注冊與發(fā)現(xiàn)伤哺。
- Broker：初始化加載本地配置，配置信息是以json格式存儲在本地者祖， rocketmq強(qiáng)依賴fastjson作轉(zhuǎn)換立莉， 通過ConfigMananger來管理配置加載以及持久化,主要負(fù)責(zé)消息的存儲、投遞和查詢以及服務(wù)高可用保證七问。
