2023 RocketMQ常見面試題50道

1、當消費負載均衡consumer和queue不對等的時候會發(fā)生什么？Consumer和queue會優(yōu)先平均分配，如果Consumer少于queue的個數(shù)，則會存在部分Consumer消費多個queue的情況，如果Consumer等于queue的個數(shù)，那就是一個Consumer消費一個queue，如果Consumer個數(shù)大于queue的個數(shù)，那么會有部分Consumer空余出來，白白的浪費了。2、消息重復消費如何解決？影響消息正常發(fā)送和消費的重要原因是網(wǎng)絡(luò)的不確定性。引起重復消費的原因ACK正常情況下在consumer真正消費完消息后應該發(fā)送ack，通知broker該消息已正常消費，從queue中剔除當ack因為網(wǎng)絡(luò)原因無法發(fā)送到broker，broker會認為詞條消息沒有被消費，此后會開啟消息重投機制把消息再次投遞到consumer消費模式在CLUSTERING模式下，消息在broker中會保證相同group的consumer消費一次，但是針對不同group的consumer會推送多次解決方案數(shù)據(jù)庫表處理消息前，使用消息主鍵在表中帶有約束的字段中insertMap單機時可以使用mapConcurrentHashMap->putIfAbsentguavacacheRedis分布式鎖搞起來。3、如何讓RocketMQ保證消息的順序消費？首先多個queue只能保證單個queue里的順序，queue是典型的FIFO，天然順序。多個queue同時消費是無法絕對保證消息的有序性的。所以總結(jié)如下：同一topic，同一個QUEUE，發(fā)消息的時候一個線程去發(fā)送消息，消費的時候一個線程去消費一個queue里的消息。4、怎么保證消息發(fā)到同一個queue？RocketMQ給我們提供了MessageQueueSelector接口，可以自己重寫里面的接口，實現(xiàn)自己的算法，舉個最簡單的例子：判斷i%2==0，那就都放到queue1里，否則放到queue2里。for(inti=0;i<5;i++){Messagemessage=newMessage("orderTopic",("hello!"+i).getBytes());producer.send(//要發(fā)的那條消息message,//queue選擇器，向topic中的哪個queue去寫消息newMessageQueueSelector(){//手動選擇一個queue@OverridepublicMessageQueueselect(//當前topic里面包含的所有queueList<MessageQueue>mqs,//具體要發(fā)的那條消息Messagemsg,//對應到send（）里的args，也就是2000前面的那個0Objectarg){//向固定的一個queue里寫消息，比如這里就是向第一個queue里寫消息if(Integer.parseInt(arg.toString())%2==0){returnmqs.get(0);}else{returnmqs.get(1);}}},//自定義參數(shù)：0//2000代表2000毫秒超時時間i,2000);}5、RocketMQ如何保證消息不丟失？首先在如下三個部分都可能會出現(xiàn)丟失消息的情況：Producer端Broker端Consumer端6、Producer端如何保證消息不丟失采取send()同步發(fā)消息，發(fā)送結(jié)果是同步感知的。發(fā)送失敗后可以重試，設(shè)置重試次數(shù)。默認3次。producer.setRetryTimesWhenSendFailed(10);集群部署，比如發(fā)送失敗了的原因可能是當前Broker宕機了，重試的時候會發(fā)送到其他Broker上。7、Broker端如何保證消息不丟失修改刷盤策略為同步刷盤。默認情況下是異步刷盤的。flushDiskType=SYNC_FLUSH集群部署，主從模式，高可用。8、Consumer端如何保證消息不丟失完全消費正常后在進行手動ack確認。9、RocketMQ的消息堆積如何處理？首先要找到是什么原因?qū)е碌南⒍逊e，是Producer太多了，Consumer太少了導致的還是說其他情況，總之先定位問題。然后看下消息消費速度是否正常，正常的話，可以通過上線更多Consumer臨時解決消息堆積問題10、如果Consumer和Queue不對等，上線了多臺也在短時間內(nèi)無法消費完堆積的消息怎么辦？準備一個臨時的topicqueue的數(shù)量是堆積的幾倍queue分布到多Broker中上線一臺Consumer做消息的搬運工，把原來Topic中的消息挪到新的Topic里，不做業(yè)務(wù)邏輯處理，只是挪過去上線N臺Consumer同時消費臨時Topic中的數(shù)據(jù)改bug恢復原來的Consumer，繼續(xù)消費之前的Topic11、堆積消息會超時刪除嗎？不會；RocketMQ中的消息只會在commitLog被刪除的時候才會消失。也就是說未被消費的消息不會存在超時刪除這情況。12、堆積的消息會不會進死信隊列？不會，消息在消費失敗后會進入重試隊列（%RETRY%+ConsumerGroup），18次才會進入死信隊列（%DLQ%+ConsumerGroup）。源碼如下：publicclassMessageStoreConfig{//每隔如下時間會進行重試，到最后一次時間重試失敗的話就進入死信隊列了。privateStringmessageDelayLevel="1s5s10s30s1m2m3m4m5m6m7m8m9m10m20m30m1h2h";}13、RocketMQ在分布式事務(wù)支持這塊機制的底層原理?分布式系統(tǒng)中的事務(wù)可以使用TCC（Try、Confirm、Cancel）、2pc來解決分布式系統(tǒng)中的消息原子性RocketMQ4.3+提供分布事務(wù)功能，通過RocketMQ事務(wù)消息能達到分布式事務(wù)的最終一致RocketMQ實現(xiàn)方式：HalfMessage：預處理消息，當broker收到此類消息后，會存儲到RMQ_SYS_TRANS_HALF_TOPIC的消息消費隊列中檢查事務(wù)狀態(tài)：Broker會開啟一個定時任務(wù)，消費RMQ_SYS_TRANS_HALF_TOPIC隊列中的消息，每次執(zhí)行任務(wù)會向消息發(fā)送者確認事務(wù)執(zhí)行狀態(tài)（提交、回滾、未知），如果是未知，Broker會定時去回調(diào)在重新檢查。超時：如果超過回查次數(shù)，默認回滾消息。也就是他并未真正進入Topic的queue，而是用了臨時queue來放所謂的halfmessage，等提交事務(wù)后才會真正的將halfmessage轉(zhuǎn)移到topic下的queue。14、RocketMQ是如何保證數(shù)據(jù)的高容錯性的?在不開啟容錯的情況下，輪詢隊列進行發(fā)送，如果失敗了，重試的時候過濾失敗的Broker如果開啟了容錯策略，會通過RocketMQ的預測機制來預測一個Broker是否可用如果上次失敗的Broker可用那么還是會選擇該Broker的隊列如果上述情況失敗，則隨機選擇一個進行發(fā)送在發(fā)送消息的時候會記錄一下調(diào)用的時間與是否報錯，根據(jù)該時間去預測broker的可用時間其實就是send消息的時候queue的選擇。源碼在如下：org.apache.rocketmq.client.latency.MQFaultStrategy#selectOneMessageQueue()15、RocketMQ如何分布式存儲海量消息的？RocketMQ進程一般稱為Broker，集群部署的各個Broker收到不同的消息，然后存儲在自己本地的磁盤文件中。16、任何一臺Broker突然宕機了怎么辦？還能使用嗎？消息會不會丟？RocketMQ的解決思路是Broker主從架構(gòu)以及多副本策略。Master收到消息后會同步給Slave，這樣一條消息就不止一份了，Master宕機了還有slave中的消息可用，保證了MQ的可靠性和高可用新。17、怎么知道有哪些Broker？如何知道要連那個Broker？有個NameServer的概念，是獨立部署在幾臺機器上的，然后所有的Broker都會把自己注冊到NameServer上去，NameServer就知道集群里有哪些Broker了!發(fā)送消息到Broker，會找NameServer去獲取路由信息系統(tǒng)要從Broker獲取消息，也會找NameServer獲取路由信息，去找到對應的Broker獲取消息。18、NameServer到底可以部署幾臺機器？為什么要集群化部署？部署多臺，保證高可用性。集群化部署是為了高可用性，NameServer是集群里非常關(guān)鍵的一個角色,如果部署一臺NameServer，宕機會導致RocketMQ集群出現(xiàn)故障，所以NameServer一定會多機器部署，實現(xiàn)一個集群，起到高可用的效果。19、系統(tǒng)如何從NameServer獲取Broker信息？系統(tǒng)主動去NameServer上拉取Broker信息及其他相關(guān)信息。20、如果Broker宕了，NameServer是怎么感知到的？Broker會定時（30s）向NameServer發(fā)送心跳然后NameServer會定時（10s）運行一個任務(wù)，去檢查一下各個Broker的最近一次心跳時間，如果某個Broker超過120s都沒發(fā)送心跳了，那么就認為這個Broker已經(jīng)掛掉了。21、Broker掛了，系統(tǒng)是怎么感知到的？主要是通過拉取NameServer上Broker的信息。但是，因為Broker心跳、NameServer定時任務(wù)、生產(chǎn)者和消費者拉取Broker信息，這些操作都是周期性的，所以不會實時感知，所以存在發(fā)送消息和消費消息失敗的情況，現(xiàn)在我們先知道，對于生產(chǎn)者而言，他是有一套容錯機制的。22、MasterBroker是如何將消息同步給SlaveBroker的？RocketMQ自身的Master-Slave模式采取的是Pull模式拉取消息。23、消費消息時是從Master獲取還是Slave獲?。靠赡軓腗asterBroker獲取消息，也有可能從SlaveBroker獲取消息消費者的系統(tǒng)在獲取消息的時候會先發(fā)送請求到MasterBroker上去，請求獲取一批消息，此時MasterBroker是會返回一批消息給消費者系統(tǒng)的MasterBroker在返回消息給消費者系統(tǒng)的時候，會根據(jù)當時MasterBroker的負載情況和SlaveBroker的同步情況，向消費者系統(tǒng)建議下一次拉取消息的時候是從MasterBroker拉取還是從SlaveBroker拉取。24、如果SlaveBroker掛掉了，會對整個系統(tǒng)有影響嗎？有一點影響，但是影響不太大，因為消息寫入全部是發(fā)送到MasterBroker的，獲取消息也可以Master獲取，少了SlaveBroker，會導致所有讀寫壓力都集中在MasterBroker25、MasterBroker突然掛了，這樣會怎么樣？RocketMQ4.5版本之前，用SlaveBroker同步數(shù)據(jù)，盡量保證數(shù)據(jù)不丟失，但是一旦Master故障了，Slave是沒法自動切換成Master的。所以在這種情況下，如果MasterBroker宕機了，這時就得手動做一些運維操作，把SlaveBroker重新修改一些配置，重啟機器給調(diào)整為MasterBroker，這是有點麻煩的，而且會導致中間一段時間不可用。RocketMQ4.5之后支持了一種叫做Dledger機制，基于Raft協(xié)議實現(xiàn)的一個機制。我們可以讓一個MasterBroker對應多個SlaveBroker，一旦MasterBroker宕機了，在多個Slave中通過Dledger技術(shù)將一個SlaveBroker選為新的MasterBroker對外提供服務(wù)。在生產(chǎn)環(huán)境中可以是用Dledger機制實現(xiàn)自動故障切換，只要10秒或者幾十秒的時間就可以完成26、為什么使用rocketMQ性能：TPS10000沒問題順序消費：可以保證一個隊列里面的消息順序消費，比如同一個訂單的消息可以放到同一個隊列這樣就達到了順序消費，如果想保證全局順序，設(shè)置一個隊列事務(wù)消息：添加事務(wù)表，實現(xiàn)TransactionListener，在本地事務(wù)提交的時候往事務(wù)表插入一條數(shù)據(jù)，mq回查消息，如果存在就commit，不存在就rollBack，回查次數(shù)自己設(shè)置思想：利用兩階段提交+補償機制27、消息隊列有哪些消息模型隊列模型：一條消息被一個消費組下面的一個消費者消費對應集群消費發(fā)布/訂閱模型：一條消息被消費組下面的所有消費者消費對應廣播消費28、如何處理消息的重復問題業(yè)務(wù)冪等：保證業(yè)務(wù)消費一條和消費多條是冪等的消息去重：為每條消息創(chuàng)建一個唯一的key，不能重復消費，比如設(shè)置唯一索引，將消息插入數(shù)據(jù)庫做判斷29、怎么處理消息積壓消費者擴容：如果隊列的個數(shù)大于消費者的個數(shù)，可以對消費者進行擴容，提高消費能力遷移消息到臨時topic：如果隊列的個數(shù)小于消費者的個數(shù)，增加消費者也不會提高消費能力，新建一個臨時的topic，用幾個消費者直接將消息丟到臨時的topic，然后創(chuàng)建幾個消費者去消費臨時的topic，這樣也是間接的加大消費能力30、怎么保證消息順序部分消息順序：將消息都發(fā)送到同一個隊列全局消息順序：配置topic為1個隊列31、如何實現(xiàn)消息過濾tag過濾sql表達式過濾filterserver自定義函數(shù)過濾32、RocketMQ怎么實現(xiàn)延時消息的發(fā)送消息的時候設(shè)置延遲級別，broker收到延時消息的時候會先將消息發(fā)送到SCHEDULE_JOB_XXX的相應時間段的隊列中，然后通過一個定時任務(wù)輪詢這些隊列，如果達到時間了就將消息發(fā)送到目標topic的隊列，然后消費者就可以正常消費消息33、事務(wù)消息怎么實現(xiàn)？1、Producer向broker發(fā)送半消息2、Producer端收到響應，消息發(fā)送成功，此時消息是半消息，標記為“不可投遞”狀態(tài)，Consumer消費不了。3、Producer端執(zhí)行本地事務(wù)。4、正常情況本地事務(wù)執(zhí)行完成，Producer向Broker發(fā)送Commit/Rollback，如果是Commit，Broker端將半消息標記為正常消息，Consumer可以消費，如果是Rollback，Broker丟棄此消息。5、異常情況，Broker端遲遲等不到二次確認。在一定時間后，會查詢所有的半消息，然后到Producer端查詢半消息的執(zhí)行情況。6、Producer端查詢本地事務(wù)的狀態(tài)7、根據(jù)事務(wù)的狀態(tài)提交commit/rollback到broker端。（5，6，7是消息回查）8、消費者段消費到消息之后，執(zhí)行本地事務(wù)，執(zhí)行本地事務(wù)。34、死信隊列了解嗎？消息消費失敗之后，會自動進行消息重試，如果達到了重試的次數(shù)仍然消費失敗，會將該消息發(fā)送到死信隊列，死信隊列的消息不會被消費者正常消費，有效期為3天，3天之后自動刪除，一個死信隊列對應一個groupid，控制臺支持對死信消息的查詢、重發(fā)、導出35、如何保證RocketMQ的高可用首先broker是集群部署，每一個master下面掛一個slave讀的高可用：如果master掛了，消費者還可以從slave讀取消息寫的高可用：由broker集群保證，單個節(jié)點出現(xiàn)問題不影響發(fā)送消息到broker，如果master掛了，可以修改slave的配置文件為master，然后啟動承載寫的功能36、RocketMQ為什么不采用zookeeper做注冊中心？基于可用性來考慮，zookeeper滿足的是CP基于性能來考慮，nameserver本身的實現(xiàn)是很輕量級，可以通過增加機器的方式水平擴展，提升集群的抗壓能力消息發(fā)送應該弱依賴于nameserver，當生產(chǎn)者第一次發(fā)送消息，從nameserver獲取到broker地址然后緩存到本地，所以nameserver集群掛了之后也不會影響生產(chǎn)者發(fā)送消息37、Broker是怎么保存數(shù)據(jù)的呢？commitlog文件：消息的主體內(nèi)容ConsumeQueue文件：基于topic的commitLog索引文件IndexFile：提供根據(jù)消息key或者時間區(qū)間查詢消息利用的操作系統(tǒng)高效讀寫的方式：PageCache、順序讀寫、零拷貝38、消息刷盤怎么實現(xiàn)的？同步刷盤：消息到達Broker內(nèi)存之后將消息刷盤到commitLog中并返回生產(chǎn)者發(fā)送成功異步刷盤：消息到達Broker內(nèi)存之后返回生產(chǎn)者發(fā)送成功，并喚醒后臺線程將數(shù)據(jù)刷盤到commitLog日志文件中，只是喚醒，不確定線程執(zhí)行的時機刷盤的最終實現(xiàn)是調(diào)用NIO的MappedByteBuffer.force()將數(shù)據(jù)刷新到磁盤39、RocketMQ的負載均衡是如何實現(xiàn)的？生產(chǎn)者端的負載均衡：索引遞增取模，如果x1m0n1x為true（默認為false），將會規(guī)避上次發(fā)送失敗的broker消費者端的負載均衡：40、RocketMQ消息長輪詢？Consumer拉取消息，如果隊列里面沒有消息不會立即返回，而是維持一個PullRequest，另外有一個線程會不斷的檢查隊列是否有消息，如果有則返回，如果到了阻塞的時間還沒有消息則返回41、RocketMQ是什么？RocketMQ是阿里巴巴在2012年開源的分布式消息中間件，目前已經(jīng)捐贈給Apache軟件基金會，并成為Apache的頂級項目。作為經(jīng)歷過多次阿里巴巴雙十一這種超級工程的洗禮并有穩(wěn)定出色表現(xiàn)的國產(chǎn)中間件，具有高性能、低延時和高可靠等特性。主要用來提升性能、系統(tǒng)解耦、流量肖峰等。42、RocketMQ有和特點？1）靈活可擴展性RocketMQ天然支持集群，其核心四組件（NameServer、Broker、Producer、Consumer）每一個都可以在沒有單點故障的情況下進行水平擴展。2）海量消息堆積能力采用零拷貝原理實現(xiàn)超大的消息的堆積能力，據(jù)說單機已可以支持億級消息堆積，而且在堆積了這么多消息后依然保持寫入低延遲。3）支持順序消息可以保證消息消費者按照消息發(fā)送的順序?qū)ο⑦M行消費。順序消息分為全局有序和局部有序，一般推薦使用局部有序，即生產(chǎn)者通過將某一類消息按順序發(fā)送至同一個隊列來實現(xiàn)。4）多種消息過濾方式消息過濾分為在服務(wù)器端過濾和在消費端過濾。服務(wù)器端過濾時可以按照消息消費者的要求做過濾，優(yōu)點是減少不必要消息傳輸，缺點是增加了消息服務(wù)器的負擔，實現(xiàn)相對復雜。消費端過濾則完全由具體應用自定義實現(xiàn)，這種方式更加靈活，缺點是很多無用的消息會傳輸給消息消費者。5）支持事務(wù)消息RocketMQ除了支持普通消息，順序消息之外還支持事務(wù)消息，這個特性對于分布式事務(wù)來說提供了又一種解決思路。6）回溯消費回溯消費是指消費者已經(jīng)消費成功的消息，由于業(yè)務(wù)上需求需要重新消費，RocketMQ支持按照時間回溯消費，時間維度精確到毫秒，可以向前回溯，也可以向后回溯。43、幾種常見MQ的比較？Kafka、ActiveMQ、RabbitMQ以及RocketMQ各自的優(yōu)缺點：特性ActiveMQRabbitMQRocketMQKafka單機吞吐量萬級萬級十萬級十萬級Topic數(shù)量對吞吐量的影響––topic可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是RocketMQ的一大優(yōu)勢，在同等機器下，可以支撐大量的topictopic從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka盡量保證topic數(shù)量不要過多，如果要支撐大規(guī)模的topic，需要增加更多的機器資源時效性毫秒級微秒級，這是RabbitMQ的一大特點，延遲最低毫秒級毫秒級可用性高，基于主從架構(gòu)實現(xiàn)高可用高非常高非常高消息可靠性有較低的概率丟失數(shù)據(jù)基本不丟經(jīng)過參數(shù)優(yōu)化配置，可以做到0丟失同RocketMQ一般的業(yè)務(wù)系統(tǒng)要引入MQ，早起大家都用ActiveMQ，但是現(xiàn)在已經(jīng)使用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗證，社區(qū)也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；后來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的Java工程師去深入研究和掌控它，對公司而言，幾乎處于不可控的狀態(tài)，但是確實人家是開源的，比較穩(wěn)定的支持，活躍度也高；不過現(xiàn)在確實越來越多的公司會去用RocketMQ，確實很不錯，畢竟是阿里出品，但社區(qū)可能有突然黃掉的風險（目前RocketMQ已捐給Apache，但GitHub上的活躍度其實不算高）對自己公司技術(shù)實力有絕對自信的，推薦用RocketMQ，否則回去老老實實用RabbitMQ吧，人家有活躍的開源社區(qū)，絕對不會黃。所以中小型公司，技術(shù)實力較為一般，技術(shù)挑戰(zhàn)不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎(chǔ)架構(gòu)研發(fā)實力較強，用RocketMQ是很好的選擇。如果是大數(shù)據(jù)領(lǐng)域的實時計算、日志采集等場景，用Kafka是業(yè)內(nèi)標準的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領(lǐng)域的事實性規(guī)范。44、RocketMQ的角色構(gòu)成？生產(chǎn)者（Producer）：負責產(chǎn)生消息，生產(chǎn)者向消息服務(wù)器發(fā)送由業(yè)務(wù)應用程序系統(tǒng)生成的消息。消費者（Consumer）：負責消費消息，消費者從消息服務(wù)器拉取信息并將其輸入用戶應用程序。消息服務(wù)器（Broker）：是消息存儲中心，主要作用是接收來自Producer的消息并存儲，Consumer從這里取得消息。名稱服務(wù)器（NameServer）：用來保存Broker相關(guān)Topic等元信息并給Producer，提供Consumer查找Broker信息。45、RocketMQ執(zhí)行流程？1）啟動Namesrv后開始監(jiān)聽端口，等待Broker、Producer、Consumer連上來，相當于一個路由控制中心。2）Broker啟動，跟所有的Namesrv保持長連接，定時發(fā)送心跳包。3）收發(fā)消息前，先創(chuàng)建Topic。創(chuàng)建Topic時，需要指定該Topic要存儲在哪些Broker上，也可以在發(fā)送消息時自動創(chuàng)建Topic。4）Producer向該Topic發(fā)送消息。5）Consumer消費該Topic的消息。RocketMQ的消息結(jié)構(gòu)？publicclassMessageimplementsSerializable{//表示消息要到