從生產者、消費者、broker、NameServe、客戶端配置、系統配置等6個方面
- 生產者
1.1 發送消息注意事項
Tags的使用（過濾消息）
一個應用盡可能用一個Topic，而消息子類型則可以用tags來標識。tags由應用設置，只有生產者在發送消息設置了tags，消費方在訂閱消息時纔可以利用tags通過broker做消息過濾：message.setTags("TagA")。
Keys的使用（消息的身份證和避免重複消費結合用）
用Keys字段唯一標識一個消息，方便將來定位消息丟失問題。服務器會爲每個消息創建索引（哈希索引），應用可以通過topic、key來查詢這條消息內容，以及消息被誰消費。由於是哈希索引，請務必保證key儘可能唯一，這樣可以避免潛在的哈希衝突。
// 訂單Id
String orderId = "20034568923546";
message.setKeys(orderId);
日誌的打印
消息發送成功或者失敗要打印消息日誌，務必要打印SendResult和key字段。send消息方法只要不拋異常，就代表發送成功。發送成功會有多個狀態，在sendResult裏定義。以下對每個狀態進行說明：
- SEND_OK
消息發送成功。要注意的是消息發送成功也不意味着它是可靠的。要確保不會丟失任何消息，還應啓用同步Master服務器或同步刷盤，即SYNC_MASTER或SYNC_FLUSH。
- FLUSH_DISK_TIMEOUT
消息發送成功但是服務器刷盤超時。此時消息已經進入服務器隊列（內存），只有服務器宕機，消息纔會丟失。消息存儲配置參數中可以設置刷盤方式和同步刷盤時間長度，如果Broker服務器設置了刷盤方式爲同步刷盤，即FlushDiskType=SYNC_FLUSH（默認爲異步刷盤方式），當Broker服務器未在同步刷盤時間內（默認爲5s）完成刷盤，則將返回該狀態——刷盤超時。
- FLUSH_SLAVE_TIMEOUT
消息發送成功，但是服務器同步到Slave時超時。此時消息已經進入服務器隊列，只有服務器宕機，消息纔會丟失。如果Broker服務器的角色是同步Master，即SYNC_MASTER（默認是異步Master即ASYNC_MASTER），並且從Broker服務器未在同步刷盤時間（默認爲5秒）內完成與主服務器的同步，則將返回該狀態——數據同步到Slave服務器超時。
- SLAVE_NOT_AVAILABLE
消息發送成功，但是此時Slave不可用。如果Broker服務器的角色是同步Master，即SYNC_MASTER（默認是異步Master服務器即ASYNC_MASTER），但沒有配置slave Broker服務器，則將返回該狀態——無Slave服務器可用。
1.2 消息發送失敗處理方式
Producer的send方法本身支持內部重試，重試邏輯如下：
- 至多重試2次（同步發送爲2次，異步發送爲0次）。
- 如果發送失敗，則輪轉到下一個Broker。這個方法的總耗時時間不超過sendMsgTimeout設置的值，默認10s。
- 如果本身向broker發送消息產生超時異常，就不會再重試。
以上策略也是在一定程度上保證了消息可以發送成功。如果業務對消息可靠性要求比較高，建議應用增加相應的重試邏輯：比如調用send同步方法發送失敗時，則嘗試將消息存儲到db，然後由後臺線程定時重試，確保消息一定到達Broker。
上述db重試方式爲什麼沒有集成到MQ客戶端內部做，而是要求應用自己去完成，主要基於以下幾點考慮：
首先，MQ的客戶端設計爲無狀態模式，方便任意的水平擴展，且對機器資源的消耗僅僅是cpu、內存、網絡。
其次，如果MQ客戶端內部集成一個KV存儲模塊，那麼數據只有同步落盤才能較可靠，而同步落盤本身性能開銷較大，所以通常會採用異步落盤，又由於應用關閉過程不受MQ運維人員控制，可能經常會發生 kill -9 這樣暴力方式關閉，造成數據沒有及時落盤而丟失。
第三，Producer所在機器的可靠性較低，一般爲虛擬機，不適合存儲重要數據。
綜上，建議重試過程交由應用來控制。
1.3 選擇oneway形式發送(日誌收集)
通常消息的發送是這樣一個過程：
- 客戶端發送請求到服務器
- 服務器處理請求
- 服務器向客戶端返回應答
所以，一次消息發送的耗時時間是上述三個步驟的總和，而某些場景要求耗時非常短，但是對可靠性要求並不高，例如日誌收集類應用，此類應用可以採用oneway形式調用，oneway形式只發送請求不等待應答，而發送請求在客戶端實現層面僅僅是一個操作系統系統調用的開銷，即將數據寫入客戶端的socket緩衝區，此過程耗時通常在微秒級。
- 消費者
2.1 消費過程冪等性（重複消費問題）
RocketMQ無法避免消息重複（Exactly-Once），所以如果業務對消費重複非常敏感，務必要在業務層面進行去重處理。可以藉助關係數據庫進行去重。首先需要確定消息的唯一鍵，可以是msgId，也可以是消息內容中的唯一標識字段，例如訂單Id等。在消費之前判斷唯一鍵是否在關係數據庫中存在。如果不存在則插入，並消費，否則跳過。（實際過程要考慮原子性問題，判斷是否存在可以嘗試插入，如果報主鍵衝突，則插入失敗，直接跳過）
msgId一定是全局唯一標識符，但是實際使用中，可能會存在相同的消息有兩個不同msgId的情況（消費者主動重發、因客戶端重投機制導致的重複等），這種情況就需要使業務字段進行重複消費。
2.2 消費速度慢的處理方式
提高消費並行度
絕大部分消息消費行爲都屬於 IO 密集型，即可能是操作數據庫，或者調用 RPC，這類消費行爲的消費速度在於後端數據庫或者外系統的吞吐量，通過增加消費並行度，可以提高總的消費吞吐量，但是並行度增加到一定程度，反而會下降。所以，應用必須要設置合理的並行度。 如下有幾種修改消費並行度的方法：
- 同一個 ConsumerGroup 下，通過增加 Consumer 實例數量來提高並行度（需要注意的是超過訂閱隊列數的 Consumer 實例無效）。可以通過加機器，或者在已有機器啓動多個進程的方式。
- 提高單個 Consumer 的消費並行線程，通過修改參數 consumeThreadMin、consumeThreadMax實現。
批量方式消費
某些業務流程如果支持批量方式消費，則可以很大程度上提高消費吞吐量，例如訂單扣款類應用，一次處理一個訂單耗時 1 s，一次處理 10 個訂單可能也只耗時 2 s，這樣即可大幅度提高消費的吞吐量，通過設置 consumer的 consumeMessageBatchMaxSize 返個參數，默認是 1，即一次只消費一條消息，例如設置爲 N，那麼每次消費的消息數小於等於 N。
跳過非重要消息
發生消息堆積時，如果消費速度一直追不上發送速度，如果業務對數據要求不高的話，可以選擇丟棄不重要的消息。例如，當某個隊列的消息數堆積到100000條以上，則嘗試丟棄部分或全部消息，這樣就可以快速追上發送消息的速度。示例代碼如下：
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 正常消費過程
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
優化每條消息消費過程
舉例如下，某條消息的消費過程如下：
- 根據消息從 DB 查詢【數據 1】
- 根據消息從 DB 查詢【數據 2】
- 複雜的業務計算
- 向 DB 插入【數據 3】
- 向 DB 插入【數據 4】
這條消息的消費過程中有4次與 DB的 交互，如果按照每次 5ms 計算，那麼總共耗時 20ms，假設業務計算耗時 5ms，那麼總過耗時 25ms，所以如果能把 4 次 DB 交互優化爲 2 次，那麼總耗時就可以優化到 15ms，即總體性能提高了 40%。所以應用如果對時延敏感的話，可以把DB部署在SSD硬盤，相比於SCSI磁盤，前者的RT會小很多。
2.3 消費打印日誌
如果消息量較少，建議在消費入口方法打印消息，消費耗時等，方便後續排查問題。
public ConsumeConcurrentlyStatus consumeMessage(
List<MessageExt> msgs,
ConsumeConcurrentlyContext context) {
log.info("RECEIVE_MSG_BEGIN: " + msgs.toString());
// TODO 正常消費過程
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
如果能打印每條消息消費耗時，那麼在排查消費慢等線上問題時，會更方便。
2.4 其他消費建議
關於消費者和訂閱
第一件需要注意的事情是，不同的消費者組可以獨立的消費一些 topic，並且每個消費者組都有自己的消費偏移量，請確保同一組內的每個消費者訂閱信息保持一致。
關於有序消息
消費者將鎖定每個消息隊列，以確保他們被逐個消費，雖然這將會導致性能下降，但是當你關心消息順序的時候會很有用。我們不建議拋出異常，你可以返回 ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT 作爲替代。
關於併發消費
顧名思義，消費者將併發消費這些消息，建議你使用它來獲得良好性能，我們不建議拋出異常，你可以返回 ConsumeConcurrentlyStatus.RECONSUME_LATER 作爲替代。
關於消費狀態Consume Status
對於併發的消費監聽器，你可以返回 RECONSUME_LATER 來通知消費者現在不能消費這條消息，並且希望可以稍後重新消費它。然後，你可以繼續消費其他消息。對於有序的消息監聽器，因爲你關心它的順序，所以不能跳過消息，但是你可以返回SUSPEND_CURRENT_QUEUE_A_MOMENT 告訴消費者等待片刻。
關於Blocking
不建議阻塞監聽器，因爲它會阻塞線程池，並最終可能會終止消費進程
關於線程數設置
消費者使用 ThreadPoolExecutor 在內部對消息進行消費，所以你可以通過設置 setConsumeThreadMin 或 setConsumeThreadMax 來改變它。
關於消費位點
當建立一個新的消費者組時，需要決定是否需要消費已經存在於 Broker 中的歷史消息CONSUME_FROM_LAST_OFFSET 將會忽略歷史消息，並消費之後生成的任何消息。CONSUME_FROM_FIRST_OFFSET 將會消費每個存在於 Broker 中的信息。你也可以使用 CONSUME_FROM_TIMESTAMP 來消費在指定時間戳後產生的消息。
- Broker
3.1 Broker 角色
Broker 角色分爲 ASYNC_MASTER（異步主機）、SYNC_MASTER（同步主機）以及SLAVE（從機）。如果對消息的可靠性要求比較嚴格，可以採用 SYNC_MASTER加SLAVE的部署方式。如果對消息可靠性要求不高，可以採用ASYNC_MASTER加SLAVE的部署方式。如果只是測試方便，則可使用僅ASYNC_MASTER或僅SYNC_MASTER的部署方式。
3.2 FlushDiskType
SYNC_FLUSH（同步刷新）相比於ASYNC_FLUSH（異步處理）會損失很多性能，但是也更可靠，所以需要根據實際的業務場景做好權衡。
3.3 broker配置
- NameServer
RocketMQ 中，Name Servers 被設計用來做簡單的路由管理。其職責包括：
- Brokers 定期向每個名稱服務器註冊路由數據。
- 名稱服務器爲客戶端，包括生產者，消費者和命令行客戶端提供最新的路由信息。
- 客戶端配置
相對於RocketMQ的Broker集羣，生產者和消費者都是客戶端。本小節主要描述生產者和消費者公共的行爲配置。
5.1 客戶端尋址方式
RocketMQ可以令客戶端找到Name Server, 然後通過Name Server再找到Broker。如下所示有多種配置方式，優先級由高到低，高優先級會覆蓋低優先級。
- 代碼中指定Name Server地址，多個namesrv地址之間用分號分割
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啓動參數中指定Name Server地址
-Drocketmq.namesrv.addr=192.168.0.1:9876;192.168.0.2:9876
- 環境變量指定Name Server地址
export NAMESRV_ADDR=192.168.0.1:9876;192.168.0.2:9876
- HTTP靜態服務器尋址（默認）
客戶端啓動後，會定時訪問一個靜態HTTP服務器，地址如下：http://jmenv.tbsite.net:8080/rocketmq/nsaddr，這個URL的返回內容如下：
192.168.0.1:9876;192.168.0.2:9876
客戶端默認每隔2分鐘訪問一次這個HTTP服務器，並更新本地的Name Server地址。URL已經在代碼中硬編碼，可通過修改/etc/hosts文件來改變要訪問的服務器，例如在/etc/hosts增加如下配置：
10.232.22.67 jmenv.taobao.net
推薦使用HTTP靜態服務器尋址方式，好處是客戶端部署簡單，且Name Server集羣可以熱升級。
5.2 客戶端配置（生產者、消費者）
DefaultMQProducer、TransactionMQProducer、DefaultMQPushConsumer、DefaultMQPullConsumer都繼承於ClientConfig類，ClientConfig爲客戶端的公共配置類。客戶端的配置都是get、set形式，每個參數都可以用spring來配置，也可以在代碼中配置，例如namesrvAddr這個參數可以這樣配置，producer.setNamesrvAddr("192.168.0.1:9876")，其他參數同理。
客戶端的公共配置
Producer配置
PushConsumer配置
PullConsumer配置
Message數據結構
6.系統配置（JVM/OS）
6.1 JVM選項
- 推薦使用最新發布的JDK 1.8版本。
- 通過設置相同的Xms和Xmx值來防止JVM調整堆大小以獲得更好的性能。簡單的JVM配置如下所示：
-server -Xms8g -Xmx8g -Xmn4g
- 如果您不關心RocketMQ Broker的啓動時間，還有一種更好的選擇，就是通過“預觸摸”Java堆以確保在JVM初始化期間每個頁面都將被分配。那些不關心啓動時間的人可以啓用它：-XX:+AlwaysPreTouch
禁用偏置鎖定可能會減少JVM暫停， -XX:-UseBiasedLocking
至於垃圾回收，建議使用帶JDK 1.8的G1收集器。
-XX:+UseG1GC -XX:G1HeapRegionSize=16m
-XX:G1ReservePercent=25
-XX:InitiatingHeapOccupancyPercent=30
這些GC選項看起來有點激進，但事實證明它在我們的生產環境中具有良好的性能。另外不要把-XX:MaxGCPauseMillis的值設置太小，否則JVM將使用一個小的年輕代來實現這個目標，這將導致非常頻繁的minor GC，所以建議使用rolling GC日誌文件：
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=30m
如果寫入GC文件會增加代理的延遲，可以考慮將GC日誌文件重定向到內存文件系統：
-Xloggc:/dev/shm/mq_gc_%p.log123
6.2 Linux內核參數
sh腳本在bin文件夾中列出了許多內核參數，可以進行微小的更改然後用於生產用途。下面的參數需要注意，更多細節請參考/proc/sys/vm/*的文檔（https://www.kernel.org/doc/Documentation/sysctl/vm.txt）
- vm.extra_free_kbytes，告訴VM在後臺回收（kswapd）啓動的閾值與直接回收（通過分配進程）的閾值之間保留額外的可用內存。RocketMQ使用此參數來避免內存分配中的長延遲。（與具體內核版本相關）
- vm.min_free_kbytes，如果將其設置爲低於1024KB，將會巧妙的將系統破壞，並且系統在高負載下容易出現死鎖。
- vm.max_map_count，限制一個進程可能具有的最大內存映射區域數。RocketMQ將使用mmap加載CommitLog和ConsumeQueue，因此建議將爲此參數設置較大的值。（agressiveness --> aggressiveness）
- vm.swappiness，定義內核交換內存頁面的積極程度。較高的值會增加攻擊性，較低的值會減少交換量。建議將值設置爲10來避免交換延遲。
- File descriptor limits，RocketMQ需要爲文件（CommitLog和ConsumeQueue）和網絡連接打開文件描述符。我們建議設置文件描述符的值爲655350。
Disk scheduler，RocketMQ建議使用I/O截止時間調度器，它試圖爲請求提供有保證的延遲。