有沒(méi)有做.net面試題的網(wǎng)站,注冊(cè)公司需要什么條件?,google官方下載app,網(wǎng)站是如何制作的了解即可一、總結(jié)RocketMQ的運(yùn)行架構(gòu)通過(guò)之前的一系列實(shí)驗(yàn)#xff0c;相信你對(duì)RocketMQ的運(yùn)行機(jī)制有了一個(gè)大概的了解。接下來(lái)我們結(jié)合一下之前實(shí)驗(yàn)的過(guò)程#xff0c;來(lái)理解一下RocketMQ的運(yùn)行架構(gòu)。下圖是RocketMQ運(yùn)行時(shí)的整體架構(gòu)#xff1a;接下來(lái)#xff0c;我們就完整…了解即可一、總結(jié)RocketMQ的運(yùn)行架構(gòu)通過(guò)之前的一系列實(shí)驗(yàn)相信你對(duì)RocketMQ的運(yùn)行機(jī)制有了一個(gè)大概的了解。接下來(lái)我們結(jié)合一下之前實(shí)驗(yàn)的過(guò)程來(lái)理解一下RocketMQ的運(yùn)行架構(gòu)。下圖是RocketMQ運(yùn)行時(shí)的整體架構(gòu)接下來(lái)我們就完整梳理一下RocketMQ中各個(gè)組件的作用1、NameServer 命名服務(wù)在我們之前的實(shí)驗(yàn)過(guò)程中你會(huì)發(fā)現(xiàn)NameServer不依賴于任何其他的服務(wù)自己獨(dú)立就能啟動(dòng)。并且不管是Broker還是客戶端都需要明確指定NameServer的服務(wù)地址。以一臺(tái)電腦為例NameServer可以理解為是整個(gè)RocketMQ的CPU整個(gè)RocketMQ集群都要在CPU的協(xié)調(diào)下才能正常工作。2、Broker 核心服務(wù)從之前的實(shí)驗(yàn)過(guò)程中你會(huì)發(fā)現(xiàn)Broker是RocketMQ中最為嬌貴的一個(gè)組件。RocketMQ提供了各種各樣的重要設(shè)計(jì)來(lái)保護(hù)Broker的安全。同時(shí)Broker也是RocketMQ中配置最為繁瑣的部分。同樣以電腦為例Broker就是整個(gè)RocketMQ中的硬盤(pán)、顯卡這一類的核心硬件。RocketMQ最核心的消息存儲(chǔ)、傳遞、查詢等功能都要由Broker提供。3、Client 客戶端Client包括消息生產(chǎn)者和消息消費(fèi)者。同樣以電腦為例Client可以認(rèn)為是RocketMQ中的鍵盤(pán)、鼠標(biāo)、顯示器這類的輸入輸出設(shè)備。鼠標(biāo)、鍵盤(pán)輸入的數(shù)據(jù)需要傳輸?shù)接脖P(pán)、顯卡等硬件才能進(jìn)行處理。但是鍵盤(pán)、鼠標(biāo)是不能直接將數(shù)據(jù)輸入到硬盤(pán)、顯卡的這就需要CPU進(jìn)行協(xié)調(diào)。通過(guò)CPU鼠標(biāo)、鍵盤(pán)就可以將輸入的數(shù)據(jù)最終傳輸?shù)胶诵牡挠布O(shè)備中。經(jīng)過(guò)硬件設(shè)備處理完成后再通過(guò)CPU協(xié)調(diào)顯示器這樣的輸出設(shè)備就能最終從核心硬件設(shè)備中獲取到輸出的數(shù)據(jù)。4、四大核心組件詳解4.1 NameServer命名服務(wù)器NameServer 是 RocketMQ 的輕量級(jí)服務(wù)發(fā)現(xiàn)與路由中心類似于 Kafka 的 Zookeeper 或 AWS SQS 的協(xié)調(diào)服務(wù)。核心職責(zé)服務(wù)注冊(cè)Broker 啟動(dòng)時(shí)向所有 NameServer 注冊(cè)自己的路由信息路由管理維護(hù) Topic 與 Broker 的映射關(guān)系心跳檢測(cè)通過(guò)定期心跳機(jī)制默認(rèn)30秒感知 Broker 的存活狀態(tài)配置管理存儲(chǔ)基礎(chǔ)的配置信息設(shè)計(jì)特點(diǎn)無(wú)狀態(tài)設(shè)計(jì)NameServer 節(jié)點(diǎn)之間不通信彼此獨(dú)立輕量級(jí)代碼量少資源消耗低部署簡(jiǎn)單最終一致性Broker 向所有 NameServer 注冊(cè)保證最終一致性4.2 Broker消息服務(wù)器Broker 是 RocketMQ 的核心組件負(fù)責(zé)消息的存儲(chǔ)、轉(zhuǎn)發(fā)和查詢。核心職責(zé)消息存儲(chǔ)將消息持久化到 CommitLog 文件消息投遞處理生產(chǎn)者的發(fā)送請(qǐng)求消息消費(fèi)處理消費(fèi)者的拉取請(qǐng)求高可用通過(guò)主從架構(gòu)實(shí)現(xiàn)數(shù)據(jù)冗余Broker 角色Master負(fù)責(zé)讀寫(xiě)操作是消息的主要處理節(jié)點(diǎn)Slave只負(fù)責(zé)讀操作作為 Master 的數(shù)據(jù)備份關(guān)鍵機(jī)制CommitLog所有 Topic 的消息順序?qū)懭胪粋€(gè)文件保證寫(xiě)入性能ConsumeQueue消費(fèi)邏輯隊(duì)列作為 CommitLog 的索引IndexFile消息索引文件支持按 Key 查詢消息4.3 Producer消息生產(chǎn)者Producer 負(fù)責(zé)生成并發(fā)送消息到 Broker。特性負(fù)載均衡自動(dòng)選擇 MessageQueue 發(fā)送消息容錯(cuò)機(jī)制支持發(fā)送失敗重試和故障轉(zhuǎn)移發(fā)送方式同步發(fā)送等待 Broker 響應(yīng)異步發(fā)送發(fā)送后不阻塞通過(guò)回調(diào)處理結(jié)果單向發(fā)送不關(guān)心發(fā)送結(jié)果追求最大吞吐量4.4 Consumer消息消費(fèi)者Consumer 負(fù)責(zé)從 Broker 拉取并消費(fèi)消息。消費(fèi)模式集群消費(fèi)Clustering同一 ConsumerGroup 的多個(gè)消費(fèi)者均攤消息廣播消費(fèi)Broadcasting同一 ConsumerGroup 的每個(gè)消費(fèi)者都接收全量消息消費(fèi)方式推模式PushBroker 主動(dòng)推送消息到 Consumer實(shí)際基于長(zhǎng)輪詢實(shí)現(xiàn)拉模式PullConsumer 主動(dòng)從 Broker 拉取消息二、理解RocketMQ的消息模型首先我們先來(lái)嘗試在RocketMQ中發(fā)送一批消息。在上一章節(jié)提到RocketMQ提供了一個(gè)測(cè)試腳本tools.sh用于快速測(cè)試RocketMQ的客戶端。在服務(wù)器上配置了一個(gè)NAMESRV_ADDR環(huán)境變量后就可以直接使用RocketMQ提供的tools.sh腳本調(diào)用RocketMQ提供的Producer示例。tools.sh org.apache.rocketmq.example.quickstart.Producer這里調(diào)用的Producer示例實(shí)際上是在RocketMQ安裝目錄下的lib/rocketmq-example-5.3.0.jar中包含的一個(gè)測(cè)試類。tools.sh腳本則是提供Producer類的運(yùn)行環(huán)境。Producer這個(gè)測(cè)試類會(huì)在RocketMQ中發(fā)送一千條測(cè)試消息。發(fā)送消息后我們可以在控制臺(tái)看到很多如下的日志信息。SendResult [sendStatusSEND_OK, msgId7F000001426E28A418FC6545DFD803E7, offsetMsgIdC0ABE88100002A9F00000000008A56E5, messageQueueMessageQueue [topicTopicTest, brokerNamebroker-a, queueId2], queueOffset124]這是RocketMQ的Broker服務(wù)端給消息生產(chǎn)者的響應(yīng)。這個(gè)響應(yīng)信息代表的是Broker服務(wù)端已經(jīng)正常接收并保存了消息生產(chǎn)者發(fā)送的消息。這里面提到了很多topic、messageQueue等概念這些是什么意思呢我們不妨先去RocketMQ的DashBoard控制臺(tái)看一下RocketMQ的Broker是如何保存這些消息的。訪問(wèn)DashBoard上的“主題”菜單可以看到多了一個(gè)名為T(mén)opicTest的主題。這個(gè)TopicTest就是我們之前運(yùn)行的Producer創(chuàng)建的主題。點(diǎn)擊“狀態(tài)”按鈕可以看到TopicTest上的消息分布。從這里可以看到TopicTest這個(gè)話題下分配了八個(gè)MessageQueue。這里的MessageQueue就是一個(gè)典型的具有FIFO先進(jìn)先出特性的消息集合。這八個(gè)MessageQueue均勻分布在了集群中的兩個(gè)Broker服務(wù)上。每個(gè)MessageQueue都記錄了一個(gè)最小位點(diǎn)和最大位點(diǎn)。這里的位點(diǎn)代表每個(gè)MessageQueue上存儲(chǔ)的消息的索引也稱為offset偏移量。每一條新記錄的消息都按照當(dāng)前最大位點(diǎn)往后分配一個(gè)新的位點(diǎn)。這個(gè)位點(diǎn)就記錄了這一條消息的存儲(chǔ)位置。從Dashboard就能看到每一個(gè)MessageQueue當(dāng)前都記錄了125條消息。也就是說(shuō)我們之前使用Producer示例在RocketMQ中發(fā)送的一千條消息就被均勻分配到了這八個(gè)MessageQueue上。這是再回頭來(lái)看之前日志中打印的SendResult的信息。日志中的MessageQueue就代表這一條消息存在哪個(gè)隊(duì)列上了。而queueOffset表示這條消息記錄在MessageQueue的哪個(gè)位置。然后我們嘗試啟動(dòng)一個(gè)消費(fèi)者來(lái)消費(fèi)消息我們同樣可以使用tools.sh來(lái)啟動(dòng)一個(gè)消費(fèi)者示例。tools.sh org.apache.rocketmq.example.quickstart.Consumer這個(gè)Consumer同樣是RocketMQ下的lib/rocketmq-example-5.3.0.jar中提供的消費(fèi)者示例。Consumer啟動(dòng)完成后我們可以在控制臺(tái)看到很多類似這樣的日志ConsumeMessageThread_3 Receive New Messages: [MessageExt [brokerNamebroker-b, queueId0, storeSize194, queueOffset95, sysFlag0, bornTimestamp1666252677571, bornHost/192.168.65.112:38414, storeTimestamp1666252678510, storeHost/192.168.65.112:10911, msgIdC0A8E88200002A9F0000000000B4ADD2, commitLogOffset11840978, bodyCRC634652396, reconsumeTimes0, preparedTransactionOffset0, toString()Message{topicTopicTest, flag0, properties{MIN_OFFSET0, MAX_OFFSET125, CONSUME_START_TIME1666257428525, UNIQ_KEY7F000001426E28A418FC6545DDC302F9, CLUSTERrocketmq-cluster, TAGSTagA}, body[72, 101, 108, 108, 111, 32, 82, 111, 99, 107, 101, 116, 77, 81, 32, 55, 54, 49], transactionIdnull}]]這里面也打印出了一些我們剛剛熟悉的brokerNamequeueIdqueueOffset這些屬性。其中queueOffset屬性就表示這一條消息在MessageQueue上的存儲(chǔ)位點(diǎn)。通過(guò)記錄每一個(gè)消息的Offset偏移量RocketMQ就可以快速的定位到這一條消息具體的存儲(chǔ)位置繼而正確讀取到消息的內(nèi)容。接下來(lái)我們還是可以到DashBoard上印證一下消息消費(fèi)的情況。在DashBoard的“主題”頁(yè)面選擇對(duì)應(yīng)主題后的“CONSUMER管理”功能就能看到消費(fèi)者的消費(fèi)情況。從這里可以看到剛才的Consumer示例啟動(dòng)了一個(gè)叫做please_rename_unique_group_name_4的消費(fèi)者組。然后這個(gè)消費(fèi)者從八個(gè)隊(duì)列中都消費(fèi)了數(shù)據(jù)。后面的代理者位點(diǎn)記錄的是當(dāng)前MessageQueue上記錄的最大消息偏移量。而消費(fèi)者位點(diǎn)記錄的是當(dāng)前消費(fèi)者組在MessageQueue上消費(fèi)的最大消息偏移量。其中的差值就表示當(dāng)前消費(fèi)者組沒(méi)有處理完的消息。并且從這里還可以看出RocketMQ記錄消費(fèi)者的消費(fèi)進(jìn)度時(shí)都是以“訂閱組”為單位的。我們也可以使用上一章節(jié)的示例自己另外定義一個(gè)新的消費(fèi)者組來(lái)消費(fèi)TopicTest上的消息。這時(shí)RocketMQ就會(huì)單獨(dú)記錄新消費(fèi)者組的消費(fèi)進(jìn)度。而新的消費(fèi)者組也能消費(fèi)到TopicTest下的所有消息。接下來(lái)我們就可以梳理出RocketMQ的消息記錄方式對(duì)之前的實(shí)驗(yàn)過(guò)程進(jìn)行梳理我們就能抽象出RocketMQ的消息模型。如下圖所示生產(chǎn)者和消費(fèi)者都可以指定一個(gè)Topic發(fā)送消息或者拉取消息。而Topic是一個(gè)邏輯概念。Topic中的消息會(huì)分布在后面多個(gè)MessageQueue當(dāng)中。這些MessageQueue會(huì)分布到一個(gè)或者多個(gè)Broker中。在RocketMQ的這個(gè)消息模型當(dāng)中最為核心的就是Topic。對(duì)于客戶端Topic代表了一類有相同業(yè)務(wù)規(guī)則的消息。對(duì)于BrokerTopic則代表了系統(tǒng)中一系列存儲(chǔ)消息的資源。所以RocketMQ對(duì)于Topic是需要做嚴(yán)格管理的。如果任由客戶端隨意創(chuàng)建Topic那么服務(wù)端的資源管理壓力就會(huì)非常大。默認(rèn)情況下Topic都需要由管理員在RocketMQ的服務(wù)端手動(dòng)進(jìn)行創(chuàng)建然后才能給客戶端使用的。而我們之前在broker.conf中手動(dòng)添加的autoCreateTopictrue就是表示可以由客戶端自行創(chuàng)建Topic。這種配置方式顯然只適用于測(cè)試環(huán)境在生產(chǎn)環(huán)境下建議關(guān)閉這個(gè)配置項(xiàng)。如果需要?jiǎng)?chuàng)建Topic可以交由運(yùn)維人員提前創(chuàng)建Topic。而對(duì)于業(yè)務(wù)來(lái)說(shuō)最為重要的就是消息Message了。生產(chǎn)者發(fā)送到某一個(gè)Topic下的消息最終會(huì)保存在Topic下的某一個(gè)MessageQueue中。而消費(fèi)者來(lái)消費(fèi)消息時(shí)RocketMQ會(huì)在Broker端給每個(gè)消費(fèi)者組記錄一個(gè)消息的消費(fèi)位點(diǎn)Offset。通過(guò)Offset控制每個(gè)消費(fèi)者組的消息處理進(jìn)度。這樣每一條消息在一個(gè)消費(fèi)者組當(dāng)中只被處理一次。從邏輯層面來(lái)看RocketMQ的消息模型和Kafka的消息模型是很相似的。沒(méi)錯(cuò)早期 RocketMQ 就是借鑒Kafka設(shè)計(jì)出來(lái)的。但是在后續(xù)的發(fā)展過(guò)程中RocketMQ在Kafka的基礎(chǔ)上做了非常大的調(diào)整。所以對(duì)于RocketMQ你也不妨回顧下Kafka與Kafka對(duì)比著進(jìn)行學(xué)習(xí)。例如在Kafka當(dāng)中如果Topic過(guò)多會(huì)造成消息吞吐量下降。但是在RocketMQ中對(duì)Topic的支持已經(jīng)得到很大的加強(qiáng)。Topic過(guò)多幾乎不會(huì)影響整體性能。RocketMQ是怎么設(shè)計(jì)的另外之前Kafka課程中也分析過(guò)Leader選舉的過(guò)程中Kafka優(yōu)先保證服務(wù)可用性而一定程度上犧牲了消息的安全性那么RocketMQ是怎么做的呢保留這些問(wèn)題后續(xù)我們一一解決。