RocketMQ 整體架構(gòu)設(shè)計(jì)

整體的架構(gòu)設(shè)計(jì)主要分為四大部分，分別是：Producer、Consumer、Broker、NameServer。

 

為了更貼合實(shí)際，我畫的都是集群部署，像 Broker 我還畫了主從。

• Producer：就是消息生產(chǎn)者，可以集群部署。它會(huì)先和 NameServer 集群中的隨機(jī)一臺(tái)建立長(zhǎng)連接，得知當(dāng)前要發(fā)送的 Topic 存在哪臺(tái) Broker Master上，然后再與其建立長(zhǎng)連接，支持多種負(fù)載平衡模式發(fā)送消息。

• Consumer：消息消費(fèi)者，也可以集群部署。它也會(huì)先和 NameServer 集群中的隨機(jī)一臺(tái)建立長(zhǎng)連接，得知當(dāng)前要消息的 Topic 存在哪臺(tái) Broker Master、Slave上，然后它們建立長(zhǎng)連接，支持集群消費(fèi)和廣播消費(fèi)消息。

• Broker：主要負(fù)責(zé)消息的存儲(chǔ)、查詢消費(fèi)，支持主從部署，一個(gè) Master 可以對(duì)應(yīng)多個(gè) Slave，Master 支持讀寫，Slave 只支持讀。Broker 會(huì)向集群中的每一臺(tái) NameServer 注冊(cè)自己的路由信息。

• NameServer：是一個(gè)很簡(jiǎn)單的 Topic 路由注冊(cè)中心，支持 Broker 的動(dòng)態(tài)注冊(cè)和發(fā)現(xiàn)，保存 Topic 和 Borker 之間的關(guān)系。通常也是集群部署，但是各 NameServer 之間不會(huì)互相通信， 各 NameServer 都有完整的路由信息，即無(wú)狀態(tài)。

我再用一段話來(lái)概括它們之間的交互：

 

先啟動(dòng) NameServer 集群，各 NameServer 之間無(wú)任何數(shù)據(jù)交互，Broker 啟動(dòng)之后會(huì)向所有 NameServer 定期（每 30s）發(fā)送心跳包，包括：IP、Port、TopicInfo，NameServer 會(huì)定期掃描 Broker 存活列表，如果超過(guò) 120s 沒(méi)有心跳則移除此 Broker 相關(guān)信息，代表下線。

這樣每個(gè) NameServer 就知道集群所有 Broker 的相關(guān)信息，此時(shí) Producer 上線從 NameServer 就可以得知它要發(fā)送的某 Topic 消息在哪個(gè) Broker 上，和對(duì)應(yīng)的 Broker （Master 角色的）建立長(zhǎng)連接，發(fā)送消息。

Consumer 上線也可以從 NameServer  得知它所要接收的 Topic 是哪個(gè) Broker ，和對(duì)應(yīng)的 Master、Slave 建立連接，接收消息。

簡(jiǎn)單的工作流程如上所述，相信大家對(duì)整體數(shù)據(jù)流轉(zhuǎn)已經(jīng)有點(diǎn)印象了，我們?cè)賮?lái)看看每個(gè)部分的詳細(xì)情況。 

NameServer

它的特點(diǎn)就是輕量級(jí)，無(wú)狀態(tài)。角色類似于 Zookeeper 的情況，從上面描述知道其主要的兩個(gè)功能就是：Broker 管理、路由信息管理。

總體而言比較簡(jiǎn)單，我再貼一些字段，讓大家有更直觀的印象知道它存儲(chǔ)了些什么。

    

Producer

Producer 無(wú)非就是消息生產(chǎn)者，那首先它得知道消息要發(fā)往哪個(gè) Broker ，于是每 30s 會(huì)從某臺(tái) NameServer 獲取 Topic 和 Broker 的映射關(guān)系存在本地內(nèi)存中，如果發(fā)現(xiàn)新的 Broker 就會(huì)和其建立長(zhǎng)連接，每 30s 會(huì)發(fā)送心跳至 Broker 維護(hù)連接。

并且會(huì)輪詢當(dāng)前可以發(fā)送的 Broker 來(lái)發(fā)送消息，達(dá)到負(fù)載均衡的目的，在同步發(fā)送情況下如果發(fā)送失敗會(huì)默認(rèn)重投兩次（retryTimesWhenSendFailed = 2），并且不會(huì)選擇上次失敗的 broker，會(huì)向其他 broker 投遞。

在異步發(fā)送失敗的情況下也會(huì)重試，默認(rèn)也是兩次 （retryTimesWhenSendAsyncFailed = 2），但是僅在同一個(gè) Broker 上重試。 

Producer 啟動(dòng)流程

然后我們?cè)賮?lái)看看 Producer 的啟動(dòng)流程看看都干了些啥。

 

大致啟動(dòng)流程圖中已經(jīng)表明的很清晰的，但是有些細(xì)節(jié)可能還不清楚，比如重平衡啊，TBW102 啥玩意啊，有哪些定時(shí)任務(wù)啊，別急都會(huì)提到的。

有人可能會(huì)問(wèn)這生產(chǎn)者為什么要啟拉取服務(wù)、重平衡？

因?yàn)?Producer 和 Consumer 都需要用 MQClientInstance，而同一個(gè) clientId 是共用一個(gè) MQClientInstance 的， clientId 是通過(guò)本機(jī) IP 和 instanceName（默認(rèn)值 default）拼起來(lái)的，所以多個(gè) Producer 、Consumer 實(shí)際用的是一個(gè)MQClientInstance。

至于有哪些定時(shí)任務(wù)，請(qǐng)看下圖：

     

Producer 發(fā)消息流程

我們?cè)賮?lái)看看發(fā)消息的流程，大致也不是很復(fù)雜，無(wú)非就是找到要發(fā)送消息的 Topic 在哪個(gè) Broker 上，然后發(fā)送消息。

 

現(xiàn)在就知道 TBW102 是啥用的，就是接受自動(dòng)創(chuàng)建主題的 Broker 啟動(dòng)會(huì)把這個(gè)默認(rèn)主題登記到 NameServer，這樣當(dāng) Producer 發(fā)送新 Topic 的消息時(shí)候就得知哪個(gè) Broker 可以自動(dòng)創(chuàng)建主題，然后發(fā)往那個(gè) Broker。

而 Broker 接受到這個(gè)消息的時(shí)候發(fā)現(xiàn)沒(méi)找到對(duì)應(yīng)的主題，但是它接受創(chuàng)建新主題，這樣就會(huì)創(chuàng)建對(duì)應(yīng)的 Topic 路由信息。 

自動(dòng)創(chuàng)建主題的弊端

自動(dòng)創(chuàng)建主題那么有可能該主題的消息都只會(huì)發(fā)往一臺(tái) Broker，起不到負(fù)載均衡的作用。

因?yàn)閯?chuàng)建新 Topic 的請(qǐng)求到達(dá) Broker 之后，Broker 創(chuàng)建對(duì)應(yīng)的路由信息，但是心跳是每 30s 發(fā)送一次，所以說(shuō) NameServer 最長(zhǎng)需要 30s 才能得知這個(gè)新 Topic 的路由信息。

假設(shè)此時(shí)發(fā)送方還在連續(xù)快速的發(fā)送消息，那 NameServer 上其實(shí)還沒(méi)有關(guān)于這個(gè) Topic 的路由信息，所以有機(jī)會(huì)讓別的允許自動(dòng)創(chuàng)建的 Broker 也創(chuàng)建對(duì)應(yīng)的 Topic 路由信息，這樣集群里的 Broker 就能接受這個(gè) Topic 的信息，達(dá)到負(fù)載均衡的目的，但也有個(gè)別 Broker 可能，沒(méi)收到。

如果發(fā)送方這一次發(fā)了之后 30s 內(nèi)一個(gè)都不發(fā)，之前的那個(gè) Broker 隨著心跳把這個(gè)路由信息更新到 NameServer 了，那么之后發(fā)送該 Topic 消息的 Producer 從 NameServer 只能得知該 Topic 消息只能發(fā)往之前的那臺(tái) Broker ，這就不均衡了，如果這個(gè)新主題消息很多，那臺(tái) Broker 負(fù)載就很高了。

所以不建議線上開啟允許自動(dòng)創(chuàng)建主題，即 autoCreateTopicEnable 參數(shù)。 

發(fā)送消息故障延遲機(jī)制

有一個(gè)參數(shù)是 sendLatencyFaultEnable，默認(rèn)不開啟。這個(gè)參數(shù)的作用是對(duì)于之前發(fā)送超時(shí)的 Broker 進(jìn)行一段時(shí)間的退避。

發(fā)送消息會(huì)記錄此時(shí)發(fā)送消息的時(shí)間，如果超過(guò)一定時(shí)間，那么此 Broker 就在一段時(shí)間內(nèi)不允許發(fā)送。

 

比如發(fā)送時(shí)間超過(guò) 15000ms 則在 600000 ms 內(nèi)無(wú)法向該 Broker 發(fā)送消息。

這個(gè)機(jī)制其實(shí)很關(guān)鍵，發(fā)送超時(shí)大概率表明此 Broker 負(fù)載高，所以先避讓一會(huì)兒，讓它緩一緩，這也是實(shí)現(xiàn)消息發(fā)送高可用的關(guān)鍵。

小結(jié)一下

Producer 每 30s 會(huì)向 NameSrv 拉取路由信息更新本地路由表，有新的 Broker 就和其建立長(zhǎng)連接，每隔 30s 發(fā)送心跳給 Broker 。

不要在生產(chǎn)環(huán)境開啟 autoCreateTopicEnable。

Producer 會(huì)通過(guò)重試和延遲機(jī)制提升消息發(fā)送的高可用。 

Broker

Broker 就比較復(fù)雜一些了，但是非常重要。大致分為以下五大模塊，我們來(lái)看一下官網(wǎng)的圖。

 

• Remoting 遠(yuǎn)程模塊，處理客戶請(qǐng)求。
• Client Manager 管理客戶端，維護(hù)訂閱的主題。
• Store Service 提供消息存儲(chǔ)查詢服務(wù)。
• HA Serivce，主從同步高可用。
• Index Serivce，通過(guò)指定key 建立索引，便于查詢。

有幾個(gè)模塊沒(méi)啥可說(shuō)的就不分析了，先看看存儲(chǔ)的。 

Broker 的存儲(chǔ)

RocketMQ 存儲(chǔ)用的是本地文件存儲(chǔ)系統(tǒng)，效率高也可靠。

主要涉及到三種類型的文件，分別是 CommitLog、ConsumeQueue、IndexFile。 

CommitLog

RocketMQ 的所有主題的消息都存在 CommitLog 中，單個(gè) CommitLog 默認(rèn) 1G，并且文件名以起始偏移量命名，固定 20 位，不足則前面補(bǔ) 0，比如 00000000000000000000 代表了第一個(gè)文件，第二個(gè)文件名就是 00000000001073741824，表明起始偏移量為 1073741824，以這樣的方式命名用偏移量就能找到對(duì)應(yīng)的文件。

所有消息都是順序?qū)懭氲模^(guò)文件大小則開啟下一個(gè)文件。 

ConsumeQueue

ConsumeQueue 消息消費(fèi)隊(duì)列，可以認(rèn)為是 CommitLog 中消息的索引，因?yàn)?CommitLog 是糅合了所有主題的消息，所以通過(guò)索引才能更加高效的查找消息。

ConsumeQueue 存儲(chǔ)的條目是固定大小，只會(huì)存儲(chǔ) 8 字節(jié)的 commitlog 物理偏移量，4 字節(jié)的消息長(zhǎng)度和 8 字節(jié) Tag 的哈希值，固定 20 字節(jié)。

在實(shí)際存儲(chǔ)中，ConsumeQueue 對(duì)應(yīng)的是一個(gè)Topic 下的某個(gè) Queue，每個(gè)文件約 5.72M，由 30w 條數(shù)據(jù)組成。

消費(fèi)者是先從 ConsumeQueue 來(lái)得到消息真實(shí)的物理地址，然后再去 CommitLog 獲取消息。 

IndexFile

IndexFile 就是索引文件，是額外提供查找消息的手段，不影響主流程。

通過(guò) Key 或者時(shí)間區(qū)間來(lái)查詢對(duì)應(yīng)的消息，文件名以創(chuàng)建時(shí)間戳命名，固定的單個(gè) IndexFile 文件大小約為400M，一個(gè) IndexFile 存儲(chǔ) 2000W個(gè)索引。

我們?cè)賮?lái)看看以上三種文件的內(nèi)容是如何生成的：

 

消息到了先存儲(chǔ)到 Commitlog，然后會(huì)有一個(gè) ReputMessageService 線程接近實(shí)時(shí)地將消息轉(zhuǎn)發(fā)給消息消費(fèi)隊(duì)列文件與索引文件，也就是說(shuō)是異步生成的。

消息刷盤機(jī)制

RocketMQ 提供消息同步刷盤和異步刷盤兩個(gè)選擇，關(guān)于刷盤我們都知道效率比較低，單純存入內(nèi)存中的話效率是最高的，但是可靠性不高，影響消息可靠性的情況大致有以下幾種：

1. Broker 被暴力關(guān)閉，比如 kill -9
2. Broker 掛了
3. 操作系統(tǒng)掛了
4. 機(jī)器斷電
5. 機(jī)器壞了，開不了機(jī)
6. 磁盤壞了

如果都是 1-4 的情況，同步刷盤肯定沒(méi)問(wèn)題，異步的話就有可能丟失部分消息，5 和 6就得依靠副本機(jī)制了，如果同步雙寫肯定是穩(wěn)的，但是性能太差，如果異步則有可能丟失部分消息。

所以需要看場(chǎng)景來(lái)使用同步、異步刷盤和副本雙寫機(jī)制。 

頁(yè)緩存與內(nèi)存映射

Commitlog 是混合存儲(chǔ)的，所以所有消息的寫入就是順序?qū)懭耄瑢?duì)文件的順序?qū)懭牒蛢?nèi)存的寫入速度基本上沒(méi)什么差別。

并且 RocketMQ 的文件都利用了內(nèi)存映射即 Mmap，將程序虛擬頁(yè)面直接映射到頁(yè)緩存上，無(wú)需有內(nèi)核態(tài)再往用戶態(tài)的拷貝，來(lái)看一下我之前文章畫的圖。

 

頁(yè)緩存其實(shí)就是操作系統(tǒng)對(duì)文件的緩存，用來(lái)加速文件的讀寫，也就是說(shuō)對(duì)文件的寫入先寫到頁(yè)緩存中，操作系統(tǒng)會(huì)不定期刷盤（時(shí)間不可控），對(duì)文件的讀會(huì)先加載到頁(yè)緩存中，并且根據(jù)局部性原理還會(huì)預(yù)讀臨近塊的內(nèi)容。

其實(shí)也是因?yàn)槭褂脙?nèi)存映射機(jī)制，所以 RocketMQ 的文件存儲(chǔ)都使用定長(zhǎng)結(jié)構(gòu)來(lái)存儲(chǔ)，方便一次將整個(gè)文件映射至內(nèi)存中。 

文件預(yù)分配和文件預(yù)熱

而內(nèi)存映射也只是做了映射，只有當(dāng)真正讀取頁(yè)面的時(shí)候產(chǎn)生缺頁(yè)中斷，才會(huì)將數(shù)據(jù)真正加載到內(nèi)存中，所以 RocketMQ 做了一些優(yōu)化，防止運(yùn)行時(shí)的性能抖動(dòng)。 

文件預(yù)分配

CommitLog 的大小默認(rèn)是1G，當(dāng)超過(guò)大小限制的時(shí)候需要準(zhǔn)備新的文件，而 RocketMQ 就起了一個(gè)后臺(tái)線程 AllocateMappedFileService，不斷的處理 AllocateRequest，AllocateRequest 其實(shí)就是預(yù)分配的請(qǐng)求，會(huì)提前準(zhǔn)備好下一個(gè)文件的分配，防止在消息寫入的過(guò)程中分配文件，產(chǎn)生抖動(dòng)。 

文件預(yù)熱

有一個(gè) warmMappedFile 方法，它會(huì)把當(dāng)前映射的文件，每一頁(yè)遍歷多去，寫入一個(gè)0字節(jié)，然后再調(diào)用mlock 和 madvise(MADV_WILLNEED)。

mlock：可以將進(jìn)程使用的部分或者全部的地址空間鎖定在物理內(nèi)存中，防止其被交換到 swap 空間。

madvise：給操作系統(tǒng)建議，說(shuō)這文件在不久的將來(lái)要訪問(wèn)的，因此，提前讀幾頁(yè)可能是個(gè)好主意。 

小結(jié)一下

CommitLog 采用混合型存儲(chǔ)，也就是所有 Topic 都存在一起，順序追加寫入，文件名用起始偏移量命名。

消息先寫入 CommitLog 再通過(guò)后臺(tái)線程分發(fā)到 ConsumerQueue 和 IndexFile 中。

消費(fèi)者先讀取 ConsumerQueue 得到真正消息的物理地址，然后訪問(wèn) CommitLog 得到真正的消息。

利用了 mmap 機(jī)制減少一次拷貝，利用文件預(yù)分配和文件預(yù)熱提高性能。

提供同步和異步刷盤，根據(jù)場(chǎng)景選擇合適的機(jī)制。 

Broker 的 HA

從 Broker 會(huì)和主 Broker 建立長(zhǎng)連接，然后獲取主 Broker commitlog 最大偏移量，開始向主 Broker 拉取消息，主 Broker 會(huì)返回一定數(shù)量的消息，循環(huán)進(jìn)行，達(dá)到主從數(shù)據(jù)同步。

消費(fèi)者消費(fèi)消息會(huì)先請(qǐng)求主 Broker ，如果主 Broker 覺得現(xiàn)在壓力有點(diǎn)大，則會(huì)返回從 Broker 拉取消息的建議，然后消費(fèi)者就去從服務(wù)器拉取消息。 

Consumer

消費(fèi)有兩種模式，分別是廣播模式和集群模式。

廣播模式：一個(gè)分組下的每個(gè)消費(fèi)者都會(huì)消費(fèi)完整的Topic 消息。

集群模式：一個(gè)分組下的消費(fèi)者瓜分消費(fèi)Topic 消息。

一般我們用的都是集群模式。

而消費(fèi)者消費(fèi)消息又分為推和拉模式，詳細(xì)看我這篇文章消息隊(duì)列推拉模式，分別從源碼級(jí)別分析了 RokcetMQ 和 Kafka 的消息推拉，以及推拉模式的優(yōu)缺點(diǎn)。 

Consumer 端的負(fù)載均衡機(jī)制

Consumer 會(huì)定期的獲取 Topic 下的隊(duì)列數(shù)，然后再去查找訂閱了該 Topic 的同一消費(fèi)組的所有消費(fèi)者信息，默認(rèn)的分配策略是類似分頁(yè)排序分配。

將隊(duì)列排好序，然后消費(fèi)者排好序，比如隊(duì)列有 9 個(gè)，消費(fèi)者有 3 個(gè)，那消費(fèi)者-1 消費(fèi)隊(duì)列 0、1、2 的消息，消費(fèi)者-2 消費(fèi)隊(duì)列 3、4、5，以此類推。

所以如果負(fù)載太大，那么就加隊(duì)列，加消費(fèi)者，通過(guò)負(fù)載均衡機(jī)制就可以感知到重平衡，均勻負(fù)載。 

Consumer 消息消費(fèi)的重試

難免會(huì)遇到消息消費(fèi)失敗的情況，所以需要提供消費(fèi)失敗的重試，而一般的消費(fèi)失敗要么就是消息結(jié)構(gòu)有誤，要么就是一些暫時(shí)無(wú)法處理的狀態(tài)，所以立即重試不太合適。

RocketMQ 會(huì)給每個(gè)消費(fèi)組都設(shè)置一個(gè)重試隊(duì)列，Topic 是 %RETRY%+consumerGroup，并且設(shè)定了很多重試級(jí)別來(lái)延遲重試的時(shí)間。

為了利用 RocketMQ 的延時(shí)隊(duì)列功能，重試的消息會(huì)先保存在 Topic 名稱為“SCHEDULE_TOPIC_XXXX”的延遲隊(duì)列，在消息的擴(kuò)展字段里面會(huì)存儲(chǔ)原來(lái)所屬的 Topic 信息。

delay 一段時(shí)間后再恢復(fù)到重試隊(duì)列中，然后 Consumer 就會(huì)消費(fèi)這個(gè)重試隊(duì)列主題，得到之前的消息。

如果超過(guò)一定的重試次數(shù)都消費(fèi)失敗，則會(huì)移入到死信隊(duì)列，即 Topic %DLQ%" + ConsumerGroup 中，存儲(chǔ)死信隊(duì)列即認(rèn)為消費(fèi)成功，因?yàn)閷?shí)在沒(méi)轍了，暫時(shí)放過(guò)。

然后我們可以通過(guò)人工來(lái)處理死信隊(duì)列的這些消息。 

消息的全局順序和局部順序

全局順序就是消除一切并發(fā)，一個(gè) Topic 一個(gè)隊(duì)列，Producer 和 Consuemr 的并發(fā)都為一。

局部順序其實(shí)就是指某個(gè)隊(duì)列順序，多隊(duì)列之間還是能并行的。

可以通過(guò) MessageQueueSelector 指定 Producer 某個(gè)業(yè)務(wù)只發(fā)這一個(gè)隊(duì)列，然后 Comsuer 通過(guò)MessageListenerOrderly 接受消息，其實(shí)就是加鎖消費(fèi)。

在 Broker 會(huì)有一個(gè) mqLockTable ，順序消息在創(chuàng)建拉取消息任務(wù)的時(shí)候需要在 Broker 鎖定該消息隊(duì)列，之后加鎖成功的才能消費(fèi)。

而嚴(yán)格的順序消息其實(shí)很難，假設(shè)現(xiàn)在都好好的，如果有個(gè) Broker 宕機(jī)了，然后發(fā)生了重平衡，隊(duì)列對(duì)應(yīng)的消費(fèi)者實(shí)例就變了，就會(huì)有可能會(huì)出現(xiàn)亂序的情況，如果要保持嚴(yán)格順序，那此時(shí)就只能讓整個(gè)集群不可用了。 

一些注意點(diǎn)

1、訂閱消息是以 ConsumerGroup 為單位存儲(chǔ)的，所以ConsumerGroup 中的每個(gè) Consumer 需要有相同的訂閱。

因?yàn)橛嗛喯⑹请S著心跳上傳的，如果一個(gè) ConsumerGroup 中 Consumer 訂閱信息不一樣，那么就會(huì)出現(xiàn)互相覆蓋的情況。

比如消費(fèi)者 A 訂閱 Topic a，消費(fèi)者 B 訂閱 Topic b，此時(shí)消費(fèi)者 A 去 Broker 拿消息，然后 B 的心跳包發(fā)出了，Broker 更新了，然后接到 A 的請(qǐng)求，一臉懵逼，沒(méi)這訂閱關(guān)系啊。

2、RocketMQ 主從讀寫分離

從只能讀，不能寫，并且只有當(dāng)前客戶端讀的 offset 和 當(dāng)前 Broker 已接受的最大 offset 超過(guò)限制的物理內(nèi)存大小時(shí)候才會(huì)去從讀，所以正常情況下從分擔(dān)不了流量

3、單單加機(jī)器提升不了消費(fèi)速度，隊(duì)列的數(shù)量也需要跟上。

4、之前提到的，不要允許自動(dòng)創(chuàng)建主題 

RocketMQ 的最佳實(shí)踐

這些最佳實(shí)踐部分參考自官網(wǎng)。 

Tags的使用

建議一個(gè)應(yīng)用一個(gè) Topic，利用 tages 來(lái)標(biāo)記不同業(yè)務(wù)，因?yàn)?tages 設(shè)置比較靈活，且一個(gè)應(yīng)用一個(gè) Topic 很清晰，能直觀的辨別。 

Keys的使用

如果有消息業(yè)務(wù)上的唯一標(biāo)識(shí)，請(qǐng)?zhí)顚懙?keys 字段中，方便日后的定位查找。 

提高 Consumer 的消費(fèi)能力

1、提高消費(fèi)并行度：增加隊(duì)列數(shù)和消費(fèi)者數(shù)量，提高單個(gè)消費(fèi)者的并行消費(fèi)線程，參數(shù) consumeThreadMax。

2、批處理消費(fèi)，設(shè)置 consumeMessageBatchMaxSize 參數(shù)，這樣一次能拿到多條消息，然后比如一個(gè) update語(yǔ)句之前要執(zhí)行十次，現(xiàn)在一次就執(zhí)行完。

3、跳過(guò)非核心的消息，當(dāng)負(fù)載很重的時(shí)候，為了保住那些核心的消息，設(shè)置那些非核心的消息，例如此時(shí)消息堆積 1W 條了之后，就直接返回消費(fèi)成功，跳過(guò)非核心消息。 

NameServer 的尋址

請(qǐng)使用 HTTP 靜態(tài)服務(wù)器尋址（默認(rèn)），這樣 NameServer 就能動(dòng)態(tài)發(fā)現(xiàn)。 

JVM選項(xiàng)

以下抄自官網(wǎng)：

如果不關(guān)心 RocketMQ Broker的啟動(dòng)時(shí)間，通過(guò)“預(yù)觸摸” Java 堆以確保在 JVM 初始化期間每個(gè)頁(yè)面都將被分配。

那些不關(guān)心啟動(dòng)時(shí)間的人可以啟用它：-XX:+AlwaysPreTouch 禁用偏置鎖定可能會(huì)減少JVM暫停， -XX:-UseBiasedLocking 至于垃圾回收，建議使用帶JDK 1.8的G1收集器。

-XX:+UseG1GC -XX:G1HeapRegionSize=16m
-XX:G1ReservePercent=25 -XX:InitiatingHeapOccupancyPercent=30

另外不要把-XX:MaxGCPauseMillis的值設(shè)置太小，否則JVM將使用一個(gè)小的年輕代來(lái)實(shí)現(xiàn)這個(gè)目標(biāo)，這將導(dǎo)致非常頻繁的minor GC，所以建議使用rolling GC日志文件:

-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=30m 

Linux內(nèi)核參數(shù)

以下抄自官網(wǎng)：

• vm.extra_free_kbytes，告訴VM在后臺(tái)回收（kswapd）啟動(dòng)的閾值與直接回收（通過(guò)分配進(jìn)程）的閾值之間保留額外的可用內(nèi)存。RocketMQ使用此參數(shù)來(lái)避免內(nèi)存分配中的長(zhǎng)延遲。（與具體內(nèi)核版本相關(guān)）
• vm.min_free_kbytes，如果將其設(shè)置為低于1024KB，將會(huì)巧妙的將系統(tǒng)破壞，并且系統(tǒng)在高負(fù)載下容易出現(xiàn)死鎖。
• vm.max_map_count，限制一個(gè)進(jìn)程可能具有的最大內(nèi)存映射區(qū)域數(shù)。RocketMQ將使用mmap加載CommitLog和ConsumeQueue，因此建議將為此參數(shù)設(shè)置較大的值。（agressiveness --> aggressiveness）
• vm.swappiness，定義內(nèi)核交換內(nèi)存頁(yè)面的積極程度。較高的值會(huì)增加攻擊性，較低的值會(huì)減少交換量。建議將值設(shè)置為10來(lái)避免交換延遲。
• File descriptor limits，RocketMQ需要為文件（CommitLog和ConsumeQueue）和網(wǎng)絡(luò)連接打開文件描述符。我們建議設(shè)置文件描述符的值為655350。
• Disk scheduler，RocketMQ建議使用I/O截止時(shí)間調(diào)度器，它試圖為請(qǐng)求提供有保證的延遲。