RocketMQ

RocketMQ

通用API
【更新時(shí)間: 2024.03.29】 RocketMQ 是由阿里慷慨捐贈(zèng)給 Apache 的重要成果,它作為一款極為出色的分布式消息中間件,具有低延遲、高并發(fā)、高可用以及高可靠等顯著特性,能夠在各種復(fù)雜場(chǎng)景中穩(wěn)定高效地實(shí)現(xiàn)消息傳遞與處理等相關(guān)服務(wù)。
瀏覽次數(shù)
34
采購(gòu)人數(shù)
0
試用次數(shù)
0
! 適用于個(gè)人&企業(yè)
收藏
×
完成
取消
×
書(shū)簽名稱
確定
RocketMQ
RocketMQ 是由阿里慷慨捐贈(zèng)給 Apache 的重要成果,它作為一款...
RocketMQ
RocketMQ 是由阿里慷慨捐贈(zèng)給 Apache 的重要成果,它作為一款...
<
產(chǎn)品介紹
>

什么是RocketMQ?

"RocketMQ" 是一款高性能、高吞吐量的分布式消息中間件,由阿里巴巴開(kāi)源并捐贈(zèng)給 Apache 軟件基金會(huì),成為 Apache RocketMQ 項(xiàng)目。它旨在處理大規(guī)模的消息傳遞需求,廣泛應(yīng)用于互聯(lián)網(wǎng)、金融、電信、物流等行業(yè)的核心業(yè)務(wù)系統(tǒng)中。

消息隊(duì)列 RocketMQ版 是基于 Apache RocketMQ 構(gòu)建的商業(yè)級(jí)消息中間件服務(wù),通常由云服務(wù)提供商(如阿里云、騰訊云等)提供。這種服務(wù)形式不僅繼承了 Apache RocketMQ 的所有核心功能和優(yōu)勢(shì),還通過(guò)云服務(wù)的方式,為用戶提供了更加便捷、靈活、可擴(kuò)展的部署和管理方案。

什么是RocketMQ接口?

由服務(wù)使用方的應(yīng)用程序發(fā)起,以Restful風(fēng)格為主、通過(guò)公網(wǎng)HTTP協(xié)議調(diào)用RocketMQ,從而實(shí)現(xiàn)程序的自動(dòng)化交互,提高服務(wù)效率。

RocketMQ有哪些核心功能?

消費(fèi)模式多樣

  1. 發(fā)布/訂閱模式:這是消息隊(duì)列最常見(jiàn)的消費(fèi)模式。生產(chǎn)者(Producer)將消息發(fā)送到指定的主題(Topic),消費(fèi)者(Consumer)訂閱該主題并接收消息。RocketMQ確保每個(gè)消息只被每個(gè)消費(fèi)者組(Consumer Group)中的一個(gè)消費(fèi)者實(shí)例消費(fèi),即使存在多個(gè)消費(fèi)者實(shí)例同時(shí)訂閱同一主題。

  2. 集群消費(fèi)模式:在集群消費(fèi)模式下,多個(gè)消費(fèi)者實(shí)例組成一個(gè)消費(fèi)者組,共同消費(fèi)同一個(gè)主題下的消息。RocketMQ通過(guò)負(fù)載均衡機(jī)制將消息均勻分配給組內(nèi)的消費(fèi)者實(shí)例,以提高消費(fèi)能力和容錯(cuò)性。

  3. 廣播消費(fèi)模式:與集群消費(fèi)模式不同,廣播消費(fèi)模式下,消息會(huì)被發(fā)送到訂閱了該主題的每個(gè)消費(fèi)者實(shí)例,而不管這些消費(fèi)者實(shí)例是否屬于同一個(gè)消費(fèi)者組。這種模式適用于需要將消息廣播給所有訂閱者的場(chǎng)景。

消息類型豐富

  1. 普通消息:最基本的消息類型,支持同步、異步和單向發(fā)送方式。

  2. 順序消息:保證消息的順序性,適用于需要按特定順序處理消息的場(chǎng)景,如訂單處理、日志收集等。

  3. 事務(wù)消息:支持分布式事務(wù)的最終一致性。生產(chǎn)者先發(fā)送半事務(wù)消息到RocketMQ,然后執(zhí)行本地事務(wù)。根據(jù)本地事務(wù)的執(zhí)行結(jié)果,生產(chǎn)者向RocketMQ發(fā)送提交或回滾請(qǐng)求。RocketMQ根據(jù)這些請(qǐng)求來(lái)處理半事務(wù)消息,確保事務(wù)的最終一致性。

  4. 定時(shí)消息延時(shí)消息:允許生產(chǎn)者指定消息在特定時(shí)間后或延遲一段時(shí)間后才被消費(fèi)。這適用于需要按時(shí)間順序處理消息的場(chǎng)景,如定時(shí)任務(wù)、預(yù)約提醒等。                                                                                                                  

監(jiān)控告警

  1. 消息查詢和回溯:支持按時(shí)間、消息ID等條件查詢消息,方便用戶回溯消息處理過(guò)程。

  2. 消息重試與死信管理:對(duì)于消費(fèi)失敗的消息,RocketMQ支持自動(dòng)重試機(jī)制。如果多次重試后仍無(wú)法消費(fèi)成功,則可以將消息發(fā)送到死信隊(duì)列中,供后續(xù)處理。

  3. 數(shù)據(jù)監(jiān)控與告警:支持對(duì)消息堆積、消費(fèi)延時(shí)等關(guān)鍵指標(biāo)進(jìn)行實(shí)時(shí)監(jiān)控,一旦達(dá)到預(yù)設(shè)的閾值,系統(tǒng)將自動(dòng)觸發(fā)告警通知相關(guān)人員。

數(shù)據(jù)安全

  1. ACL訪問(wèn)策略:支持配置ACL(Access Control List)訪問(wèn)策略,通過(guò)密鑰管理實(shí)現(xiàn)數(shù)據(jù)面的鑒權(quán)和授權(quán)。這有助于防止未經(jīng)授權(quán)的訪問(wèn)和數(shù)據(jù)泄露。

  2. 密鑰管理:提供密鑰管理服務(wù),用于生成、存儲(chǔ)和管理訪問(wèn)密鑰。這些密鑰用于加密和解密消息內(nèi)容或認(rèn)證消息發(fā)送者和接收者的身份。

  3. 私有網(wǎng)絡(luò)(VPC):支持將RocketMQ部署在私有網(wǎng)絡(luò)中,通過(guò)VPC加強(qiáng)網(wǎng)絡(luò)訪問(wèn)控制。這有助于隔離外部網(wǎng)絡(luò)流量和保護(hù)內(nèi)部數(shù)據(jù)資源的安全。

RocketMQ的技術(shù)原理是什么?

  1. 角色組成
    • NameServer:一個(gè)幾乎無(wú)狀態(tài)的節(jié)點(diǎn),可集群部署,節(jié)點(diǎn)之間無(wú)任何信息同步。主要用來(lái)管理Broker的地址信息,為Producer和Consumer提供路由查詢服務(wù)。
    • Broker:RocketMQ的核心組成部分,負(fù)責(zé)消息的存儲(chǔ)和轉(zhuǎn)發(fā)。Broker支持消息Push和Pull模式,支持千億級(jí)別的消息堆積能力。
    • Producer:消息生產(chǎn)者,和NameServer通信獲取topic路由信息,和NameServer保持長(zhǎng)連接以及和該生產(chǎn)者關(guān)聯(lián)的所有broker保持長(zhǎng)連接。
    • Consumer:消費(fèi)者,單個(gè)消費(fèi)者和一臺(tái)NameServer保持長(zhǎng)連接,定時(shí)查詢topic配置信息,根據(jù)topic路由和Broker保持長(zhǎng)連接。
  2. 消息流程
    • 消息發(fā)布:Producer首先向NameServer查詢目標(biāo)Topic所在的Broker地址,然后將消息發(fā)送到這個(gè)Broker。
    • 消息存儲(chǔ):Broker接收到消息后,將消息存儲(chǔ)在磁盤(pán)或內(nèi)存中。為了提高效率,Broker會(huì)批量將消息存儲(chǔ)到磁盤(pán)。
    • 消息訂閱:Consumer啟動(dòng)時(shí),向NameServer查詢并訂閱其感興趣的Topic,NameServer返回對(duì)應(yīng)的Broker地址。然后,Consumer直接和Broker建立連接,進(jìn)行消息拉取或等待Broker推送消息。
    • 主從同步:為了保證數(shù)據(jù)的可靠性和高可用性,Broker可以配置為主從模式。在此模式下,主Broker負(fù)責(zé)處理讀寫(xiě)請(qǐng)求,同時(shí)將數(shù)據(jù)同步到從Broker,以保證在主Broker宕機(jī)時(shí),從Broker可以接管服務(wù)。
  3. 負(fù)載均衡
    • RocketMQ支持集群模式,可以通過(guò)增加Broker實(shí)例來(lái)水平擴(kuò)展系統(tǒng)的處理能力。同時(shí),它在Producer和Consumer端都實(shí)現(xiàn)了負(fù)載均衡,確保消息的均勻分布和消費(fèi)。
  4. 消息確認(rèn)與重試機(jī)制
    • 消費(fèi)者處理消息后,需要向Broker發(fā)送確認(rèn)信息。如果Broker在規(guī)定時(shí)間內(nèi)沒(méi)有收到確認(rèn),它會(huì)重新投遞該消息。
    • 當(dāng)消息消費(fèi)失敗時(shí),RocketMQ支持自動(dòng)重試,增強(qiáng)了消息處理的可靠性。

RocketMQ的核心優(yōu)勢(shì)是什么?

標(biāo)準(zhǔn)API接口
我們提供標(biāo)準(zhǔn)的API接口和詳細(xì)的接入文檔,幫助用戶快速、便捷地將服務(wù)集成到自己的應(yīng)用程序中。接入流程簡(jiǎn)單明了,無(wú)需復(fù)雜的配置和調(diào)試即可實(shí)現(xiàn)快速接入。

服務(wù)商賬號(hào)統(tǒng)一管理
用戶在冪簡(jiǎn)平臺(tái)根據(jù)已使用的API服務(wù)采購(gòu)API服務(wù)商的賬號(hào)后,并在冪簡(jiǎn)平臺(tái)進(jìn)行創(chuàng)建、綁定、解綁等操作。通過(guò)采集分離的工具,使用賬號(hào)資源進(jìn)行產(chǎn)品運(yùn)營(yíng)

零代碼集成服務(wù)商
通過(guò)一套改進(jìn)過(guò)的流程來(lái)實(shí)現(xiàn)研發(fā)過(guò)程的零采購(gòu)、零干擾。讓程序員優(yōu)先對(duì)接API服務(wù),匹配業(yè)務(wù)需求,驗(yàn)證項(xiàng)目可行性上線之后再啟動(dòng)采購(gòu),24小時(shí)內(nèi)即可上線運(yùn)行

智能路由
采用智能路由規(guī)則,動(dòng)態(tài)分配識(shí)別通道,有效提升了驗(yàn)證的準(zhǔn)確率,其性能高于同行業(yè)平臺(tái),通過(guò)不斷優(yōu)化算法和模型,確保精準(zhǔn)度和準(zhǔn)確性

 

服務(wù)擴(kuò)展

服務(wù)擴(kuò)展不僅提供特性配置和歸屬地查詢等增值服務(wù),還能根據(jù)用戶需求靈活定制解決方案,滿足多樣化的業(yè)務(wù)場(chǎng)景,進(jìn)一步提升用戶體驗(yàn)和滿意度。

 

可視化監(jiān)控
專注于性能和安全,通過(guò)監(jiān)控調(diào)用量、成功率、響應(yīng)時(shí)間和狀態(tài)碼來(lái)優(yōu)化請(qǐng)求效率。安全機(jī)制利用網(wǎng)關(guān)和策略嚴(yán)格控制訪問(wèn),防止違規(guī)調(diào)用。異常監(jiān)控快速識(shí)別服務(wù)中斷,確保穩(wěn)定性和可靠性

在哪些場(chǎng)景會(huì)用到RocketMQ?

1. 異步解耦

在復(fù)雜的企業(yè)級(jí)應(yīng)用架構(gòu)中,"RocketMQ"的API接口被廣泛應(yīng)用于實(shí)現(xiàn)高效的異步通信機(jī)制,從而有效地解除多個(gè)業(yè)務(wù)系統(tǒng)之間的緊密耦合。這種解耦不僅提升了系統(tǒng)的靈活性和可擴(kuò)展性,還保證了整體業(yè)務(wù)的連續(xù)性和穩(wěn)定性。具體場(chǎng)景包括但不限于:

  • 微服務(wù)架構(gòu)中的服務(wù)間通信:在微服務(wù)架構(gòu)中,服務(wù)間的調(diào)用往往涉及復(fù)雜的依賴關(guān)系。通過(guò)RocketMQ,服務(wù)間的調(diào)用可以轉(zhuǎn)變?yōu)楫惒较鬟f,服務(wù)生產(chǎn)者發(fā)送消息后無(wú)需等待響應(yīng)即可繼續(xù)處理其他任務(wù),而服務(wù)消費(fèi)者則可以根據(jù)自身處理能力異步接收并處理消息。這種方式顯著降低了服務(wù)間的耦合度,提高了系統(tǒng)的響應(yīng)速度和吞吐量。

  • 訂單處理與支付確認(rèn):在電商系統(tǒng)中,訂單生成后通常需要調(diào)用支付服務(wù)進(jìn)行支付確認(rèn)。如果采用同步調(diào)用方式,訂單服務(wù)將等待支付服務(wù)響應(yīng)后才能繼續(xù)后續(xù)流程,這可能導(dǎo)致系統(tǒng)性能瓶頸。通過(guò)RocketMQ,訂單服務(wù)可以將支付請(qǐng)求作為消息發(fā)送到隊(duì)列中,由支付服務(wù)異步處理并返回結(jié)果。這樣,訂單服務(wù)可以立即返回給用戶訂單已提交的響應(yīng),而無(wú)需等待支付服務(wù)的實(shí)際處理結(jié)果。

2. 削峰填谷

面對(duì)高并發(fā)、高流量的業(yè)務(wù)場(chǎng)景,"RocketMQ"的API接口作為流量緩沖器,發(fā)揮著至關(guān)重要的作用。它能夠有效地收集上游系統(tǒng)的突增請(qǐng)求,并按照下游系統(tǒng)的實(shí)際消費(fèi)能力平滑處理消息,從而避免系統(tǒng)過(guò)載和崩潰。具體場(chǎng)景包括:

  • 大促活動(dòng)期間的流量控制:在電商大促期間,用戶訪問(wèn)量和訂單量會(huì)急劇增加,給系統(tǒng)帶來(lái)巨大壓力。通過(guò)RocketMQ,可以將用戶請(qǐng)求和訂單信息異步發(fā)送到消息隊(duì)列中,由后端服務(wù)按需消費(fèi)處理。這樣,即使上游系統(tǒng)面臨巨大的流量沖擊,下游系統(tǒng)也能保持穩(wěn)定的處理能力,確保業(yè)務(wù)平穩(wěn)運(yùn)行。

  • 數(shù)據(jù)同步與批量處理:在數(shù)據(jù)密集型應(yīng)用中,如日志收集、用戶行為分析等場(chǎng)景,系統(tǒng)需要實(shí)時(shí)或定期地將大量數(shù)據(jù)從一個(gè)系統(tǒng)同步到另一個(gè)系統(tǒng)。通過(guò)RocketMQ,可以將數(shù)據(jù)同步請(qǐng)求作為消息發(fā)送到隊(duì)列中,由專門(mén)的消費(fèi)者服務(wù)進(jìn)行批量處理和同步。這種方式不僅可以降低系統(tǒng)間的耦合度,還可以提高數(shù)據(jù)同步的效率和可靠性。

3. 順序收發(fā)

在某些業(yè)務(wù)場(chǎng)景中,消息的順序性至關(guān)重要,如訂單處理、金融交易等。"RocketMQ"提供了順序消息的機(jī)制,確保消息的先進(jìn)先出(FIFO)順序,并支持全局和分區(qū)順序消費(fèi),滿足不同場(chǎng)景下的需求。

  • 訂單處理流程:在電商系統(tǒng)中,訂單的處理通常涉及多個(gè)步驟,如支付確認(rèn)、庫(kù)存扣減、物流分配等。這些步驟需要按照嚴(yán)格的順序進(jìn)行,以確保訂單的正確性和一致性。通過(guò)RocketMQ的順序消息功能,可以確保訂單相關(guān)的消息按照生成順序被消費(fèi)處理,從而避免訂單處理過(guò)程中的混亂和錯(cuò)誤。

  • 金融交易記錄:在金融系統(tǒng)中,交易記錄的生成和處理也需要保持嚴(yán)格的順序性。通過(guò)RocketMQ的分區(qū)順序消費(fèi)功能,可以將同一交易類型的消息發(fā)送到同一個(gè)分區(qū)中,確保這些消息被順序消費(fèi)處理。同時(shí),分區(qū)順序消費(fèi)還支持動(dòng)態(tài)擴(kuò)展功能,可以根據(jù)業(yè)務(wù)量的增長(zhǎng)靈活調(diào)整分區(qū)數(shù)量,提高系統(tǒng)的可擴(kuò)展性和處理能力。

4. 消息追蹤與審計(jì)

在需要高度監(jiān)管和合規(guī)性要求的行業(yè)中,如金融、醫(yī)療等,消息的追蹤與審計(jì)是不可或缺的一部分。這些行業(yè)往往需要對(duì)數(shù)據(jù)的完整性、準(zhǔn)確性和安全性進(jìn)行嚴(yán)格的監(jiān)控和記錄,以確保業(yè)務(wù)操作符合法規(guī)要求,同時(shí)預(yù)防潛在的風(fēng)險(xiǎn)和漏洞。"RocketMQ"的API接口在此類場(chǎng)景中發(fā)揮了重要作用,它不僅支持高效的消息傳遞,還提供了強(qiáng)大的消息追蹤和審計(jì)功能。

  • 訂消息追蹤:在金融交易中,每一筆交易都伴隨著多條消息的產(chǎn)生和處理。為了確保交易的透明度和可追溯性,需要對(duì)這些消息進(jìn)行詳細(xì)的追蹤。RocketMQ通過(guò)其監(jiān)控中心和API接口,提供了消息軌跡的查詢功能,可以實(shí)時(shí)查看消息的發(fā)送時(shí)間、發(fā)送者、接收者、接收時(shí)間以及處理結(jié)果等關(guān)鍵信息。這有助于快速定位問(wèn)題、排查故障,并在必要時(shí)進(jìn)行審計(jì)和調(diào)查。

  • 審計(jì)日志:在醫(yī)療系統(tǒng)中,患者的健康數(shù)據(jù)和醫(yī)療記錄是極其敏感和重要的。為了確保數(shù)據(jù)的合規(guī)性和安全性,醫(yī)療機(jī)構(gòu)需要對(duì)所有涉及患者數(shù)據(jù)的操作進(jìn)行詳細(xì)的審計(jì)和記錄。RocketMQ的日志系統(tǒng)可以與現(xiàn)有的審計(jì)系統(tǒng)集成,自動(dòng)記錄每一條消息的發(fā)送、接收和處理過(guò)程,包括消息的內(nèi)容、時(shí)間戳、操作員等信息。這些審計(jì)日志可以作為法律證據(jù),用于證明醫(yī)療操作的合規(guī)性和正確性,同時(shí)也為后續(xù)的故障排查和改進(jìn)提供了寶貴的參考。

<
產(chǎn)品問(wèn)答
>
?
角色組成: NameServer:一個(gè)幾乎無(wú)狀態(tài)的節(jié)點(diǎn),可集群部署,節(jié)點(diǎn)之間無(wú)任何信息同步。主要用來(lái)...
消費(fèi)組必須保證消費(fèi)關(guān)系和邏輯完全一致。業(yè)務(wù)服務(wù)集群更新時(shí),訂閱關(guān)系可能會(huì)出現(xiàn)不一致,這時(shí)候只有交集是可靠消費(fèi),差集是不可靠消費(fèi)。需要快速修正訂閱關(guān)系,確保所有節(jié)點(diǎn)訂閱的Topic一致。
?
同一個(gè)消息會(huì)被消費(fèi)多次嗎?
RocketMQ已經(jīng)做到了同一個(gè)consumer group只會(huì)消費(fèi)一次,但如果有業(yè)務(wù)消費(fèi)冪等的需求(如生產(chǎn)中存在灰度服,服務(wù)版本大于正式服),仍然需要在消費(fèi)邏輯中增加冪等處理。
?
持續(xù)生產(chǎn)的消息,在沒(méi)有消費(fèi)組的情況下會(huì)積壓?jiǎn)幔?
會(huì)積壓。一直沒(méi)有消費(fèi)組的話,消息會(huì)按照一定策略(如48小時(shí)后)被清理。如果消息很重要,需要增加消費(fèi)組的節(jié)點(diǎn)來(lái)增加消費(fèi)速度,或者重置commitlog的offset。
?
消費(fèi)組和Topic需要提前創(chuàng)建嗎?
一般情況下,建議消費(fèi)組和Topic提前創(chuàng)建好。但RocketMQ也支持動(dòng)態(tài)創(chuàng)建Topic和消費(fèi)組,不過(guò)需要注意相關(guān)的配置和可能的警告信息。
?
Broker的部署模式有哪些?
單Master模式:這是最簡(jiǎn)單的部署方式,但風(fēng)險(xiǎn)較大。只有一個(gè)Master節(jié)點(diǎn),沒(méi)有Slave節(jié)點(diǎn),一旦Master節(jié)點(diǎn)重啟或宕機(jī),服務(wù)將不可用。這種模式一般用于測(cè)試環(huán)境,不建議在生產(chǎn)環(huán)境使用。 多Master模式:集群中全部為Master節(jié)點(diǎn),沒(méi)有Slave節(jié)點(diǎn)。優(yōu)點(diǎn)是配置簡(jiǎn)單,單個(gè)Master節(jié)點(diǎn)宕機(jī)對(duì)應(yīng)用影響較小,且性能較高。但缺點(diǎn)是當(dāng)單個(gè)Master節(jié)點(diǎn)宕機(jī)時(shí),該節(jié)點(diǎn)上未被消費(fèi)的消息在節(jié)點(diǎn)恢復(fù)之前不可訂閱,會(huì)影響消息的實(shí)時(shí)性。 多Master多Slave模式(異步復(fù)制):每個(gè)Master節(jié)點(diǎn)配置一個(gè)或多個(gè)Slave節(jié)點(diǎn),HA(高可用)采用異步復(fù)制方式。這種方式下,消息寫(xiě)入Master后即返回成功ACK,然后主備之間異步同步消息。優(yōu)點(diǎn)是即使磁盤(pán)損壞,消息丟失的很少,且Master宕機(jī)后消費(fèi)者仍可從Slave消費(fèi),對(duì)應(yīng)用透明。但缺點(diǎn)是主備之間有短暫的消息延遲,且Master宕機(jī)、磁盤(pán)損壞情況下會(huì)丟失少量消息。 多Master多Slave模式(同步雙寫(xiě)):與異步復(fù)制模式類似,但主備之間采用同步雙寫(xiě)方式,即只有主備都寫(xiě)成功才向應(yīng)用返回成功。這種方式下,數(shù)據(jù)與服務(wù)都無(wú)單點(diǎn)故障,Master宕機(jī)情況下消息無(wú)延遲,服務(wù)可用性與數(shù)據(jù)可用性都非常高。但缺點(diǎn)是性能比異步復(fù)制模式略低,發(fā)送單個(gè)消息的RT會(huì)略高。
<
最可能同場(chǎng)景使用的其他API
>
API接口列表
<
依賴服務(wù)
>
<
產(chǎn)品問(wèn)答
>
?
角色組成: NameServer:一個(gè)幾乎無(wú)狀態(tài)的節(jié)點(diǎn),可集群部署,節(jié)點(diǎn)之間無(wú)任何信息同步。主要用來(lái)...
消費(fèi)組必須保證消費(fèi)關(guān)系和邏輯完全一致。業(yè)務(wù)服務(wù)集群更新時(shí),訂閱關(guān)系可能會(huì)出現(xiàn)不一致,這時(shí)候只有交集是可靠消費(fèi),差集是不可靠消費(fèi)。需要快速修正訂閱關(guān)系,確保所有節(jié)點(diǎn)訂閱的Topic一致。
?
同一個(gè)消息會(huì)被消費(fèi)多次嗎?
RocketMQ已經(jīng)做到了同一個(gè)consumer group只會(huì)消費(fèi)一次,但如果有業(yè)務(wù)消費(fèi)冪等的需求(如生產(chǎn)中存在灰度服,服務(wù)版本大于正式服),仍然需要在消費(fèi)邏輯中增加冪等處理。
?
持續(xù)生產(chǎn)的消息,在沒(méi)有消費(fèi)組的情況下會(huì)積壓?jiǎn)幔?
會(huì)積壓。一直沒(méi)有消費(fèi)組的話,消息會(huì)按照一定策略(如48小時(shí)后)被清理。如果消息很重要,需要增加消費(fèi)組的節(jié)點(diǎn)來(lái)增加消費(fèi)速度,或者重置commitlog的offset。
?
消費(fèi)組和Topic需要提前創(chuàng)建嗎?
一般情況下,建議消費(fèi)組和Topic提前創(chuàng)建好。但RocketMQ也支持動(dòng)態(tài)創(chuàng)建Topic和消費(fèi)組,不過(guò)需要注意相關(guān)的配置和可能的警告信息。
?
Broker的部署模式有哪些?
單Master模式:這是最簡(jiǎn)單的部署方式,但風(fēng)險(xiǎn)較大。只有一個(gè)Master節(jié)點(diǎn),沒(méi)有Slave節(jié)點(diǎn),一旦Master節(jié)點(diǎn)重啟或宕機(jī),服務(wù)將不可用。這種模式一般用于測(cè)試環(huán)境,不建議在生產(chǎn)環(huán)境使用。 多Master模式:集群中全部為Master節(jié)點(diǎn),沒(méi)有Slave節(jié)點(diǎn)。優(yōu)點(diǎn)是配置簡(jiǎn)單,單個(gè)Master節(jié)點(diǎn)宕機(jī)對(duì)應(yīng)用影響較小,且性能較高。但缺點(diǎn)是當(dāng)單個(gè)Master節(jié)點(diǎn)宕機(jī)時(shí),該節(jié)點(diǎn)上未被消費(fèi)的消息在節(jié)點(diǎn)恢復(fù)之前不可訂閱,會(huì)影響消息的實(shí)時(shí)性。 多Master多Slave模式(異步復(fù)制):每個(gè)Master節(jié)點(diǎn)配置一個(gè)或多個(gè)Slave節(jié)點(diǎn),HA(高可用)采用異步復(fù)制方式。這種方式下,消息寫(xiě)入Master后即返回成功ACK,然后主備之間異步同步消息。優(yōu)點(diǎn)是即使磁盤(pán)損壞,消息丟失的很少,且Master宕機(jī)后消費(fèi)者仍可從Slave消費(fèi),對(duì)應(yīng)用透明。但缺點(diǎn)是主備之間有短暫的消息延遲,且Master宕機(jī)、磁盤(pán)損壞情況下會(huì)丟失少量消息。 多Master多Slave模式(同步雙寫(xiě)):與異步復(fù)制模式類似,但主備之間采用同步雙寫(xiě)方式,即只有主備都寫(xiě)成功才向應(yīng)用返回成功。這種方式下,數(shù)據(jù)與服務(wù)都無(wú)單點(diǎn)故障,Master宕機(jī)情況下消息無(wú)延遲,服務(wù)可用性與數(shù)據(jù)可用性都非常高。但缺點(diǎn)是性能比異步復(fù)制模式略低,發(fā)送單個(gè)消息的RT會(huì)略高。
<
最可能同場(chǎng)景使用的其他API
>