1 生產(chǎn)者

1.1 發(fā)送消息注意事項(xiàng)

1 Tags的使用

一個(gè)應(yīng)用盡可能用一個(gè)Topic，而消息子類型則可以用tags來(lái)標(biāo)識(shí)壳贪。tags可以由應(yīng)用自由設(shè)置箫津，只有生產(chǎn)者在發(fā)送消息設(shè)置了tags愈污，消費(fèi)方在訂閱消息時(shí)才可以利用tags通過(guò)broker做消息過(guò)濾：message.setTags("TagA")碍扔。

2 Keys的使用

每個(gè)消息在業(yè)務(wù)層面的唯一標(biāo)識(shí)碼要設(shè)置到keys字段，方便將來(lái)定位消息丟失問(wèn)題家制。服務(wù)器會(huì)為每個(gè)消息創(chuàng)建索引（哈希索引）正林，應(yīng)用可以通過(guò)topic、key來(lái)查詢這條消息內(nèi)容颤殴，以及消息被誰(shuí)消費(fèi)觅廓。由于是哈希索引，請(qǐng)務(wù)必保證key盡可能唯一涵但，這樣可以避免潛在的哈希沖突杈绸。

 // 訂單Id 
 String orderId = "20034568923546"; 
 message.setKeys(orderId); 

3 日志的打印

?消息發(fā)送成功或者失敗要打印消息日志，務(wù)必要打印SendResult和key字段矮瘟。send消息方法只要不拋異常瞳脓，就代表發(fā)送成功。發(fā)送成功會(huì)有多個(gè)狀態(tài)澈侠，在sendResult里定義劫侧。以下對(duì)每個(gè)狀態(tài)進(jìn)行說(shuō)明：

• SEND_OK

消息發(fā)送成功。要注意的是消息發(fā)送成功也不意味著它是可靠的哨啃。要確保不會(huì)丟失任何消息烧栋，還應(yīng)啟用同步Master服務(wù)器或同步刷盤，即SYNC_MASTER或SYNC_FLUSH拳球。

• FLUSH_DISK_TIMEOUT

消息發(fā)送成功但是服務(wù)器刷盤超時(shí)审姓。此時(shí)消息已經(jīng)進(jìn)入服務(wù)器隊(duì)列（內(nèi)存），只有服務(wù)器宕機(jī)醇坝，消息才會(huì)丟失邑跪。消息存儲(chǔ)配置參數(shù)中可以設(shè)置刷盤方式和同步刷盤時(shí)間長(zhǎng)度，如果Broker服務(wù)器設(shè)置了刷盤方式為同步刷盤呼猪，即FlushDiskType=SYNC_FLUSH（默認(rèn)為異步刷盤方式），當(dāng)Broker服務(wù)器未在同步刷盤時(shí)間內(nèi)（默認(rèn)為5s）完成刷盤砸琅，則將返回該狀態(tài)——刷盤超時(shí)宋距。

• FLUSH_SLAVE_TIMEOUT

消息發(fā)送成功，但是服務(wù)器同步到Slave時(shí)超時(shí)症脂。此時(shí)消息已經(jīng)進(jìn)入服務(wù)器隊(duì)列谚赎，只有服務(wù)器宕機(jī)淫僻，消息才會(huì)丟失。如果Broker服務(wù)器的角色是同步Master壶唤，即SYNC_MASTER（默認(rèn)是異步Master即ASYNC_MASTER）雳灵，并且從Broker服務(wù)器未在同步刷盤時(shí)間（默認(rèn)為5秒）內(nèi)完成與主服務(wù)器的同步，則將返回該狀態(tài)——數(shù)據(jù)同步到Slave服務(wù)器超時(shí)闸盔。

• SLAVE_NOT_AVAILABLE

消息發(fā)送成功悯辙，但是此時(shí)Slave不可用。如果Broker服務(wù)器的角色是同步Master迎吵，即SYNC_MASTER（默認(rèn)是異步Master服務(wù)器即ASYNC_MASTER）躲撰，但沒有配置slave Broker服務(wù)器，則將返回該狀態(tài)——無(wú)Slave服務(wù)器可用击费。

1.2 消息發(fā)送失敗處理方式

Producer的send方法本身支持內(nèi)部重試拢蛋，重試邏輯如下：

• 至多重試2次（同步發(fā)送為2次，異步發(fā)送為0次）蔫巩。
• 如果發(fā)送失敗谆棱，則輪轉(zhuǎn)到下一個(gè)Broker。這個(gè)方法的總耗時(shí)時(shí)間不超過(guò)sendMsgTimeout設(shè)置的值圆仔，默認(rèn)10s础锐。
• 如果本身向broker發(fā)送消息產(chǎn)生超時(shí)異常，就不會(huì)再重試荧缘。

以上策略也是在一定程度上保證了消息可以發(fā)送成功皆警。如果業(yè)務(wù)對(duì)消息可靠性要求比較高，建議應(yīng)用增加相應(yīng)的重試邏輯：比如調(diào)用send同步方法發(fā)送失敗時(shí)截粗，則嘗試將消息存儲(chǔ)到db信姓，然后由后臺(tái)線程定時(shí)重試，確保消息一定到達(dá)Broker绸罗。

上述db重試方式為什么沒有集成到MQ客戶端內(nèi)部做意推，而是要求應(yīng)用自己去完成，主要基于以下幾點(diǎn)考慮：首先珊蟀，MQ的客戶端設(shè)計(jì)為無(wú)狀態(tài)模式，方便任意的水平擴(kuò)展育灸，且對(duì)機(jī)器資源的消耗僅僅是cpu、內(nèi)存磅崭、網(wǎng)絡(luò)愉适。其次犯助，如果MQ客戶端內(nèi)部集成一個(gè)KV存儲(chǔ)模塊剂买，那么數(shù)據(jù)只有同步落盤才能較可靠，而同步落盤本身性能開銷較大腰湾，所以通常會(huì)采用異步落盤雷恃，又由于應(yīng)用關(guān)閉過(guò)程不受MQ運(yùn)維人員控制，可能經(jīng)常會(huì)發(fā)生 kill -9 這樣暴力方式關(guān)閉费坊，造成數(shù)據(jù)沒有及時(shí)落盤而丟失倒槐。第三，Producer所在機(jī)器的可靠性較低附井，一般為虛擬機(jī)讨越，不適合存儲(chǔ)重要數(shù)據(jù)。綜上永毅，建議重試過(guò)程交由應(yīng)用來(lái)控制把跨。

1.3選擇oneway形式發(fā)送

通常消息的發(fā)送是這樣一個(gè)過(guò)程：

• 客戶端發(fā)送請(qǐng)求到服務(wù)器
• 服務(wù)器處理請(qǐng)求
• 服務(wù)器向客戶端返回應(yīng)答

所以，一次消息發(fā)送的耗時(shí)時(shí)間是上述三個(gè)步驟的總和沼死，而某些場(chǎng)景要求耗時(shí)非常短着逐，但是對(duì)可靠性要求并不高，例如日志收集類應(yīng)用意蛀，此類應(yīng)用可以采用oneway形式調(diào)用耸别，oneway形式只發(fā)送請(qǐng)求不等待應(yīng)答，而發(fā)送請(qǐng)求在客戶端實(shí)現(xiàn)層面僅僅是一個(gè)操作系統(tǒng)系統(tǒng)調(diào)用的開銷县钥，即將數(shù)據(jù)寫入客戶端的socket緩沖區(qū)秀姐，此過(guò)程耗時(shí)通常在微秒級(jí)。

2 消費(fèi)者

2.1 消費(fèi)過(guò)程冪等

RocketMQ無(wú)法避免消息重復(fù)（Exactly-Once）若贮，所以如果業(yè)務(wù)對(duì)消費(fèi)重復(fù)非常敏感省有，務(wù)必要在業(yè)務(wù)層面進(jìn)行去重處理∏绰螅可以借助關(guān)系數(shù)據(jù)庫(kù)進(jìn)行去重蠢沿。首先需要確定消息的唯一鍵，可以是msgId细移，也可以是消息內(nèi)容中的唯一標(biāo)識(shí)字段搏予，例如訂單Id等。在消費(fèi)之前判斷唯一鍵是否在關(guān)系數(shù)據(jù)庫(kù)中存在弧轧。如果不存在則插入雪侥，并消費(fèi)，否則跳過(guò)精绎。（實(shí)際過(guò)程要考慮原子性問(wèn)題速缨，判斷是否存在可以嘗試插入，如果報(bào)主鍵沖突代乃，則插入失敗旬牲，直接跳過(guò)）

msgId一定是全局唯一標(biāo)識(shí)符，但是實(shí)際使用中搁吓，可能會(huì)存在相同的消息有兩個(gè)不同msgId的情況（消費(fèi)者主動(dòng)重發(fā)原茅、因客戶端重投機(jī)制導(dǎo)致的重復(fù)等），這種情況就需要使業(yè)務(wù)字段進(jìn)行重復(fù)消費(fèi)堕仔。

2.2 消費(fèi)速度慢的處理方式

1 提高消費(fèi)并行度

絕大部分消息消費(fèi)行為都屬于 IO 密集型擂橘，即可能是操作數(shù)據(jù)庫(kù)，或者調(diào)用 RPC摩骨，這類消費(fèi)行為的消費(fèi)速度在于后端數(shù)據(jù)庫(kù)或者外系統(tǒng)的吞吐量通贞，通過(guò)增加消費(fèi)并行度，可以提高總的消費(fèi)吞吐量恼五，但是并行度增加到一定程度昌罩，反而會(huì)下降婴梧。所以无拗，應(yīng)用必須要設(shè)置合理的并行度。 如下有幾種修改消費(fèi)并行度的方法：

• 同一個(gè) ConsumerGroup 下昌抠，通過(guò)增加 Consumer 實(shí)例數(shù)量來(lái)提高并行度（需要注意的是超過(guò)訂閱隊(duì)列數(shù)的 Consumer 實(shí)例無(wú)效）睬罗」旃Γ可以通過(guò)加機(jī)器，或者在已有機(jī)器啟動(dòng)多個(gè)進(jìn)程的方式傅物。
• 提高單個(gè) Consumer 的消費(fèi)并行線程夯辖，通過(guò)修改參數(shù) consumeThreadMin、consumeThreadMax實(shí)現(xiàn)董饰。

2 批量方式消費(fèi)

某些業(yè)務(wù)流程如果支持批量方式消費(fèi)蒿褂，則可以很大程度上提高消費(fèi)吞吐量，例如訂單扣款類應(yīng)用卒暂，一次處理一個(gè)訂單耗時(shí) 1 s啄栓，一次處理 10 個(gè)訂單可能也只耗時(shí) 2 s，這樣即可大幅度提高消費(fèi)的吞吐量也祠，通過(guò)設(shè)置 consumer的 consumeMessageBatchMaxSize 返個(gè)參數(shù)昙楚，默認(rèn)是 1，即一次只消費(fèi)一條消息诈嘿，例如設(shè)置為 N堪旧，那么每次消費(fèi)的消息數(shù)小于等于 N削葱。

3 跳過(guò)非重要消息

發(fā)生消息堆積時(shí)，如果消費(fèi)速度一直追不上發(fā)送速度淳梦，如果業(yè)務(wù)對(duì)數(shù)據(jù)要求不高的話析砸，可以選擇丟棄不重要的消息。例如爆袍，當(dāng)某個(gè)隊(duì)列的消息數(shù)堆積到100000條以上首繁，則嘗試丟棄部分或全部消息，這樣就可以快速追上發(fā)送消息的速度陨囊。示例代碼如下：

public ConsumeConcurrentlyStatus consumeMessage(
 List<MessageExt> msgs,
 ConsumeConcurrentlyContext context) {
 long offset = msgs.get(0).getQueueOffset();
 String maxOffset =
 msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET);
 long diff = Long.parseLong(maxOffset) - offset;
 if (diff > 100000) {
 // TODO 消息堆積情況的特殊處理
 return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
 }
 // TODO 正常消費(fèi)過(guò)程
 return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
 }

4 優(yōu)化每條消息消費(fèi)過(guò)程

舉例如下弦疮，某條消息的消費(fèi)過(guò)程如下：

• 根據(jù)消息從 DB 查詢【數(shù)據(jù) 1】
• 根據(jù)消息從 DB 查詢【數(shù)據(jù) 2】
• 復(fù)雜的業(yè)務(wù)計(jì)算
• 向 DB 插入【數(shù)據(jù) 3】
• 向 DB 插入【數(shù)據(jù) 4】

這條消息的消費(fèi)過(guò)程中有4次與 DB的 交互，如果按照每次 5ms 計(jì)算蜘醋，那么總共耗時(shí) 20ms胁塞，假設(shè)業(yè)務(wù)計(jì)算耗時(shí) 5ms，那么總過(guò)耗時(shí) 25ms堂湖，所以如果能把 4 次 DB 交互優(yōu)化為 2 次闲先，那么總耗時(shí)就可以優(yōu)化到 15ms，即總體性能提高了 40%无蜂。所以應(yīng)用如果對(duì)時(shí)延敏感的話伺糠，可以把DB部署在SSD硬盤，相比于SCSI磁盤斥季，前者的RT會(huì)小很多训桶。

2.3 消費(fèi)打印日志

如果消息量較少，建議在消費(fèi)入口方法打印消息酣倾，消費(fèi)耗時(shí)等舵揭，方便后續(xù)排查問(wèn)題。

public ConsumeConcurrentlyStatus consumeMessage(
 List<MessageExt> msgs,
 ConsumeConcurrentlyContext context) {
 log.info("RECEIVE_MSG_BEGIN: " + msgs.toString());
 // TODO 正常消費(fèi)過(guò)程
 return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
 }

如果能打印每條消息消費(fèi)耗時(shí)躁锡，那么在排查消費(fèi)慢等線上問(wèn)題時(shí)午绳，會(huì)更方便。

2.4 其他消費(fèi)建議

1 關(guān)于消費(fèi)者和訂閱

?第一件需要注意的事情是映之，不同的消費(fèi)者組可以獨(dú)立的消費(fèi)一些 topic拦焚，并且每個(gè)消費(fèi)者組都有自己的消費(fèi)偏移量，請(qǐng)確保同一組內(nèi)的每個(gè)消費(fèi)者訂閱信息保持一致杠输。

2 關(guān)于有序消息

消費(fèi)者將鎖定每個(gè)消息隊(duì)列赎败，以確保他們被逐個(gè)消費(fèi)，雖然這將會(huì)導(dǎo)致性能下降蠢甲，但是當(dāng)你關(guān)心消息順序的時(shí)候會(huì)很有用僵刮。我們不建議拋出異常，你可以返回 ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT 作為替代。

3 關(guān)于并發(fā)消費(fèi)

顧名思義搞糕，消費(fèi)者將并發(fā)消費(fèi)這些消息勇吊，建議你使用它來(lái)獲得良好性能，我們不建議拋出異常寞宫，你可以返回 ConsumeConcurrentlyStatus.RECONSUME_LATER 作為替代萧福。

4 關(guān)于消費(fèi)狀態(tài)Consume Status

對(duì)于并發(fā)的消費(fèi)監(jiān)聽器拉鹃，你可以返回 RECONSUME_LATER 來(lái)通知消費(fèi)者現(xiàn)在不能消費(fèi)這條消息辈赋，并且希望可以稍后重新消費(fèi)它。然后膏燕，你可以繼續(xù)消費(fèi)其他消息钥屈。對(duì)于有序的消息監(jiān)聽器，因?yàn)槟汴P(guān)心它的順序坝辫，所以不能跳過(guò)消息篷就，但是你可以返回SUSPEND_CURRENT_QUEUE_A_MOMENT 告訴消費(fèi)者等待片刻。

5 關(guān)于Blocking

不建議阻塞監(jiān)聽器近忙，因?yàn)樗鼤?huì)阻塞線程池竭业，并最終可能會(huì)終止消費(fèi)進(jìn)程

6 關(guān)于線程數(shù)設(shè)置

消費(fèi)者使用 ThreadPoolExecutor 在內(nèi)部對(duì)消息進(jìn)行消費(fèi)，所以你可以通過(guò)設(shè)置 setConsumeThreadMin 或 setConsumeThreadMax 來(lái)改變它及舍。

7 關(guān)于消費(fèi)位點(diǎn)

當(dāng)建立一個(gè)新的消費(fèi)者組時(shí)未辆，需要決定是否需要消費(fèi)已經(jīng)存在于 Broker 中的歷史消息CONSUME_FROM_LAST_OFFSET 將會(huì)忽略歷史消息，并消費(fèi)之后生成的任何消息锯玛。CONSUME_FROM_FIRST_OFFSET 將會(huì)消費(fèi)每個(gè)存在于 Broker 中的信息咐柜。你也可以使用 CONSUME_FROM_TIMESTAMP 來(lái)消費(fèi)在指定時(shí)間戳后產(chǎn)生的消息。

3 Broker

3.1 Broker 角色

? Broker 角色分為 ASYNC_MASTER（異步主機(jī)）攘残、SYNC_MASTER（同步主機(jī)）以及SLAVE（從機(jī)）拙友。如果對(duì)消息的可靠性要求比較嚴(yán)格，可以采用 SYNC_MASTER加SLAVE的部署方式歼郭。如果對(duì)消息可靠性要求不高遗契，可以采用ASYNC_MASTER加SLAVE的部署方式。如果只是測(cè)試方便病曾，則可以選擇僅ASYNC_MASTER或僅SYNC_MASTER的部署方式牍蜂。

3.2 FlushDiskType

? SYNC_FLUSH（同步刷新）相比于ASYNC_FLUSH（異步處理）會(huì)損失很多性能，但是也更可靠知态，所以需要根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景做好權(quán)衡捷兰。

3.3 Broker 配置

4 NameServer

?RocketMQ 中顶考，Name Servers 被設(shè)計(jì)用來(lái)做簡(jiǎn)單的路由管理赁还。其職責(zé)包括：

• Brokers 定期向每個(gè)名稱服務(wù)器注冊(cè)路由數(shù)據(jù)。
• 名稱服務(wù)器為客戶端驹沿，包括生產(chǎn)者艘策，消費(fèi)者和命令行客戶端提供最新的路由信息。 ?
  ?

5 客戶端配置

? 相對(duì)于RocketMQ的Broker集群渊季，生產(chǎn)者和消費(fèi)者都是客戶端朋蔫。本小節(jié)主要描述生產(chǎn)者和消費(fèi)者公共的行為配置。

5.1 客戶端尋址方式

RocketMQ可以令客戶端找到Name Server, 然后通過(guò)Name Server再找到Broker却汉。如下所示有多種配置方式驯妄，優(yōu)先級(jí)由高到低，高優(yōu)先級(jí)會(huì)覆蓋低優(yōu)先級(jí)合砂。

• 代碼中指定Name Server地址青扔，多個(gè)namesrv地址之間用分號(hào)分割

producer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876"); 

consumer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");

• Java啟動(dòng)參數(shù)中指定Name Server地址

-Drocketmq.namesrv.addr=192.168.0.1:9876;192.168.0.2:9876

• 環(huán)境變量指定Name Server地址

export NAMESRV_ADDR=192.168.0.1:9876;192.168.0.2:9876

• HTTP靜態(tài)服務(wù)器尋址（默認(rèn)）

客戶端啟動(dòng)后，會(huì)定時(shí)訪問(wèn)一個(gè)靜態(tài)HTTP服務(wù)器翩伪，地址如下：http://jmenv.tbsite.net:8080/rocketmq/nsaddr微猖，這個(gè)URL的返回內(nèi)容如下：
192.168.0.1:9876;192.168.0.2:9876
客戶端默認(rèn)每隔2分鐘訪問(wèn)一次這個(gè)HTTP服務(wù)器，并更新本地的Name Server地址缘屹。URL已經(jīng)在代碼中硬編碼凛剥，可通過(guò)修改/etc/hosts文件來(lái)改變要訪問(wèn)的服務(wù)器，例如在/etc/hosts增加如下配置：
10.232.22.67 jmenv.erbadagang.net
推薦使用HTTP靜態(tài)服務(wù)器尋址方式囊颅，好處是客戶端部署簡(jiǎn)單当悔，且Name Server集群可以熱升級(jí)。

5.2 客戶端配置

DefaultMQProducer踢代、TransactionMQProducer盲憎、DefaultMQPushConsumer、DefaultMQPullConsumer都繼承于ClientConfig類胳挎，ClientConfig為客戶端的公共配置類饼疙。客戶端的配置都是get慕爬、set形式窑眯，每個(gè)參數(shù)都可以用spring來(lái)配置，也可以在代碼中配置医窿，例如namesrvAddr這個(gè)參數(shù)可以這樣配置磅甩，producer.setNamesrvAddr("192.168.0.1:9876")，其他參數(shù)同理姥卢。

1 客戶端的公共配置

2 Producer配置

3 PushConsumer配置

4 PullConsumer配置

5 Message數(shù)據(jù)結(jié)構(gòu)

6 系統(tǒng)配置

本小節(jié)主要介紹系統(tǒng)（JVM/OS）相關(guān)的配置仲翎。

6.1 JVM選項(xiàng)

? 推薦使用最新發(fā)布的JDK 1.8版本。通過(guò)設(shè)置相同的Xms和Xmx值來(lái)防止JVM調(diào)整堆大小以獲得更好的性能铛漓。簡(jiǎn)單的JVM配置如下所示： ?
?? ?-server -Xms8g -Xmx8g -Xmn4g ? ? ?
如果您不關(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

? 這些GC選項(xiàng)看起來(lái)有點(diǎn)激進(jìn)湿镀，但事實(shí)證明它在我們的生產(chǎn)環(huán)境中具有良好的性能。另外不要把-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</pre>

如果寫入GC文件會(huì)增加代理的延遲塞耕，可以考慮將GC日志文件重定向到內(nèi)存文件系統(tǒng)：

-Xloggc:/dev/shm/mq_gc_%p.log123

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

? os.sh腳本在bin文件夾中列出了許多內(nèi)核參數(shù)，可以進(jìn)行微小的更改然后用于生產(chǎn)用途嘴瓤。下面的參數(shù)需要注意扫外，更多細(xì)節(jié)請(qǐng)參考/proc/sys/vm/*的文檔

• 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)求提供有保證的延遲聂使。