2023 RocketMQ常見(jiàn)面試題50道_第1頁(yè)
2023 RocketMQ常見(jiàn)面試題50道_第2頁(yè)
2023 RocketMQ常見(jiàn)面試題50道_第3頁(yè)
2023 RocketMQ常見(jiàn)面試題50道_第4頁(yè)
2023 RocketMQ常見(jiàn)面試題50道_第5頁(yè)
已閱讀5頁(yè),還剩18頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

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

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論