消息隊列（Message Queue，簡稱 MQ）是構(gòu)建分布式互聯(lián)網(wǎng)應(yīng)用的基礎(chǔ)設(shè)施，通過 MQ 實現(xiàn)的松耦合架構(gòu)設(shè)計可以提高系統(tǒng)可用性以及可擴展性，是適用于現(xiàn)代應(yīng)用的最佳設(shè)計方案。
什么是RocketMQ
RocketMQ官方定義為一個統(tǒng)一的消息傳遞引擎,輕量級的數(shù)據(jù)處理平臺。
Apache RocketMQ是分布式和低延遲消息和流處理平臺,性能和可靠性高,trillion-level（萬億級）能力和靈活的可擴展性。它由四個部分組成: 消息生產(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ā)送不需要。 消息消費者（Consumer）：負責(zé)消費消息，一般是后臺系統(tǒng)負責(zé)異步消費。一個消息消費者會從Broker服務(wù)器拉取消息、并將其提供給應(yīng)用程序。從用戶應(yīng)用的角度而言提供了兩種消費形式：拉取式消費、推動式消費。 代理服務(wù)器（Broker Server）：消息中轉(zhuǎn)角色，負責(zé)存儲消息、轉(zhuǎn)發(fā)消息。代理服務(wù)器在RocketMQ系統(tǒng)中負責(zé)接收從生產(chǎn)者發(fā)送來的消息并存儲、同時為消費者的拉取請求作準備。代理服務(wù)器也存儲消息相關(guān)的元數(shù)據(jù)，包括消費者組、消費進度偏移和主題和隊列消息等。 名字服務(wù)（Name Server）：名稱服務(wù)充當(dāng)路由消息的提供者。生產(chǎn)者或消費者能夠通過名字服務(wù)查找各主題相應(yīng)的Broker IP列表。多個Namesrv實例組成集群，但相互獨立，沒有信息交換。 其他相關(guān)概念解釋： 主題（Topic）：表示一類消息的集合，每個主題包含若干條消息，每條消息只能屬于一個主題，是RocketMQ進行消息訂閱的基本單位。 消息（Message）：消息系統(tǒng)所傳輸信息的物理載體，生產(chǎn)和消費數(shù)據(jù)的最小單位，每條消息必須屬于一個主題。RocketMQ中每個消息擁有唯一的Message ID，且可以攜帶具有業(yè)務(wù)標(biāo)識的Key。系統(tǒng)提供了通過Message ID和Key查詢消息的功能。 標(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)。消費者可以根據(jù)Tag實現(xiàn)對不同子主題的不同消費邏輯，實現(xiàn)更好的擴展性。 拉取式消費（Pull Consumer）：Consumer消費的一種類型，應(yīng)用通常主動調(diào)用Consumer的拉消息方法從Broker服務(wù)器拉消息、主動權(quán)由應(yīng)用控制。一旦獲取了批量消息，應(yīng)用就會啟動消費過程。 推動式消費（Push Consumer）：Consumer消費的一種類型，該模式下Broker收到數(shù)據(jù)后會主動推送給消費端，該消費模式一般實時性較高。 生產(chǎn)者組（Producer Group）：同一類Producer的集合，這類Producer發(fā)送同一類消息且發(fā)送邏輯一致。如果發(fā)送的是事務(wù)消息且原始生產(chǎn)者在發(fā)送之后崩潰，則Broker服務(wù)器會聯(lián)系同一生產(chǎn)者組的其他生產(chǎn)者實例以提交或回溯消費。 消費者組（Consumer Group）：同一類Consumer的集合，這類Consumer通常消費同一類消息且消費邏輯一致。消費者組使得在消息消費方面，實現(xiàn)負載均衡和容錯的目標(biāo)變得非常容易。要注意的是，消費者組的消費者實例必須訂閱完全相同的Topic。RocketMQ 支持兩種消息模式：集群消費（Clustering）和廣播消費（Broadcasting）。 集群消費（Clustering）：集群消費模式下,相同Consumer Group的每個Consumer實例平均分攤消息。 廣播消費（Broadcasting）：廣播消費模式下，相同Consumer Group的每個Consumer實例都接收全量的消息。 普通順序消息（Normal Ordered Message）：普通順序消費模式下，消費者通過同一個消息隊列（ Topic 分區(qū)，稱作 Message Queue） 收到的消息是有順序的，不同消息隊列收到的消息則可能是無順序的。 嚴格順序消息（Strictly Ordered Message）：嚴格順序消息模式下，消費者收到的所有消息均是有順序的。 消息模型（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)成。
RocketMQ特性
訂閱與發(fā)布
消息的發(fā)布是指某個生產(chǎn)者向某個topic發(fā)送消息；消息的訂閱是指某個消費者關(guān)注了某個topic中帶有某些tag的消息，進而從該topic消費數(shù)據(jù)。
消息順序
消息有序指的是一類消息消費時，能按照發(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ū)的關(guān)鍵字段，和普通消息的 Key 是完全不同的概念。 適用場景：性能要求高，以 sharding key 作為分區(qū)字段，在同一個區(qū)塊中嚴格的按照 FIFO 原則進行消息發(fā)布和消費的場景。
消息過濾
RocketMQ的消費者可以根據(jù)Tag進行消息過濾，也支持自定義屬性過濾。消息過濾目前是在Broker端實現(xiàn)的，優(yōu)點是減少了對于Consumer無用消息的網(wǎng)絡(luò)傳輸，缺點是增加了Broker的負擔(dān)、而且實現(xiàn)相對復(fù)雜。
消息可靠性
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版本開始支持同步雙寫。
至少一次
至少一次(At least Once)指每個消息必須投遞一次。Consumer先Pull消息到本地，消費完成后，才向服務(wù)器返回ack，如果沒有消費一定不會ack消息，所以RocketMQ可以很好的支持此特性。
回溯消費
回溯消費是指Consumer已經(jīng)消費成功的消息，由于業(yè)務(wù)上需求需要重新消費，要支持此功能，Broker在向Consumer投遞成功消息后，消息仍然需要保留。并且重新消費一般是按照時間維度，例如由于Consumer系統(tǒng)故障，恢復(fù)后需要重新消費1小時前的數(shù)據(jù)，那么Broker要提供一種機制，可以按照時間維度來回退消費進度。RocketMQ支持按照時間回溯消費，時間維度精確到毫秒。
事務(wù)消息
RocketMQ事務(wù)消息（Transactional Message）是指應(yīng)用本地事務(wù)和發(fā)送消息操作可以被定義到全局事務(wù)中，要么同時成功，要么同時失敗。RocketMQ的事務(wù)消息提供類似 X/Open XA 的分布事務(wù)功能，通過事務(wù)消息能達到分布式事務(wù)的最終一致。
定時消息
定時消息（延遲隊列）是指消息發(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?？梢耘渲米远xmessageDelayLevel。注意，messageDelayLevel是broker的屬性，不屬于某個topic。發(fā)消息時，設(shè)置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都會變高。
消息重試
Consumer消費消息失敗后，要提供一種重試機制，令消息再消費一次。Consumer消費消息失敗通?？梢哉J為有以下幾種情況：
- 由于消息本身的原因，例如反序列化失敗，消息數(shù)據(jù)本身無法處理（例如話費充值，當(dāng)前消息的手機號被注銷，無法充值）等。這種錯誤通常需要跳過這條消息，再消費其它消息，而這條失敗的消息即使立刻重試消費，99%也不成功，所以最好提供一種定時重試機制，即過10秒后再重試。
- 由于依賴的下游應(yīng)用服務(wù)不可用，例如db連接不可用，外系統(tǒng)網(wǎng)絡(luò)不可達等。遇到這種錯誤，即使跳過當(dāng)前失敗的消息，消費其他消息同樣也會報錯。這種情況建議應(yīng)用sleep 30s，再消費下一條消息，這樣可以減輕Broker重試消息的壓力。
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”的重試隊列中。
消息重投
生產(chǎn)者在發(fā)送消息時，同步消息失敗會重投，異步消息有重試，oneway沒有任何保證。消息重投保證消息盡可能發(fā)送成功、不丟失，但可能會造成消息重復(fù)，消息重復(fù)在RocketMQ中是無法避免的問題。消息重復(fù)在一般情況下不會發(fā)生，當(dāng)出現(xiàn)消息量大、網(wǎng)絡(luò)抖動，消息重復(fù)就會是大概率事件。另外，生產(chǎn)者主動重發(fā)、consumer負載變化也會導(dǎo)致重復(fù)消息。如下方法可以設(shè)置消息重試策略：
- retryTimesWhenSendFailed:同步發(fā)送失敗重投次數(shù)，默認為2，因此生產(chǎn)者會最多嘗試發(fā)送retryTimesWhenSendFailed + 1次。不會選擇上次失敗的broker，嘗試向其他broker發(fā)送，最大程度保證消息不丟。超過重投次數(shù)，拋出異常，由客戶端保證消息不丟。當(dāng)出現(xiàn)RemotingException、MQClientException和部分MQBrokerException時會重投。
- retryTimesWhenSendAsyncFailed:異步發(fā)送失敗重試次數(shù)，異步重試不會選擇其他broker，僅在同一個broker上做重試，不保證消息不丟。
- retryAnotherBrokerWhenNotStoreOK:消息刷盤（主或備）超時或slave不可用（返回狀態(tài)非SEND_OK），是否嘗試發(fā)送到其他broker，默認false。十分重要消息可以開啟。
流量控制
生產(chǎn)者流控，因為broker處理能力達到瓶頸；消費者流控，因為消費能力達到瓶頸。 生產(chǎn)者流控：
- commitLog文件被鎖時間超過osPageCacheBusyTimeOutMills時，參數(shù)默認為1000ms，返回流控。
- 如果開啟transientStorePoolEnable == true，且broker為異步刷盤的主機，且transientStorePool中資源不足，拒絕當(dāng)前send請求，返回流控。
- broker每隔10ms檢查send請求隊列頭部請求的等待時間，如果超過waitTimeMillsInSendQueue，默認200ms，拒絕當(dāng)前send請求，返回流控。
- broker通過拒絕send 請求方式實現(xiàn)流量控制。
注意，生產(chǎn)者流控，不會嘗試消息重投。 消費者流控：
- 消費者本地緩存消息數(shù)超過pullThresholdForQueue時，默認1000。
- 消費者本地緩存消息大小超過pullThresholdSizeForQueue時，默認100MB。
- 消費者本地緩存消息跨度超過consumeConcurrentlyMaxSpan時，默認2000。
消費者流控的結(jié)果是降低拉取頻率。
死信隊列
死信隊列用于處理無法被正常消費的消息。當(dāng)一條消息初次消費失敗，消息隊列會自動進行消息重試；達到最大重試次數(shù)后，若消費依然失敗，則表明消費者在正常情況下無法正確地消費該消息，此時，消息隊列 不會立刻將消息丟棄，而是將其發(fā)送到該消費者對應(yīng)的特殊隊列中。 RocketMQ將這種正常情況下無法被消費的消息稱為死信消息（Dead-Letter Message），將存儲死信消息的特殊隊列稱為死信隊列（Dead-Letter Queue）。在RocketMQ中，可以通過使用console控制臺對死信隊列中的消息進行重發(fā)來使得消費者實例再次進行消費。
