1.RocketMQ如何避免重複消費？
RocketMQ本身不保證消息重複消費，如果業務有要求不能重複消費，需要在自身的業務處理，常見的操作有兩種;
- 接口冪等，消費端業務消息保持冪等性，例如redis的setNx()命令，當然要注意設置key的超時時間，以及key的唯一性。
- redis的Incr命令，確定消息的唯一值，在set之前先判斷值是否存在，同時也是需要注意超時時間。
2.RocketMQ如何保證消息的可靠性傳輸，以及如何處理丟失？
- produce端：1.不採用oneway發送，使用同步或者異步方式發送，做好重試，但是重試的MessageKey必須唯一；2.投遞的日誌需要保存，關鍵字段，投遞時間，重試次數，請求體，響應體。
- broker端：1.雙主雙從架構，NamerServer需要多節點；2.同步雙寫，異步刷盤（同步刷盤則可靠性更高，但性能稍差，可根據業務選擇）。
- consumer端：1.消息消費日誌必須保留，即消息的元數據和數據體；2.消費端務必做好冪等處理。
- 投遞到broker端後：1.機器斷電重啓：異步刷盤，消息丟失；同步刷盤，消息不丟失；2.硬件故障：可能存在丟失，看隊列架構。
3.消息發生大量堆積怎麼處理？
問題描述：消息堆積了10個小時，有幾千萬條數據堆積，如何處理？
問題描述：修復consumer，然後慢慢消費，需要幾個小時才能完成，新的消息怎麼辦?
處理辦法：臨時topic隊列擴容，並提高消費能力，但是如果增加consumer數量，堆積的topic裏面的message queue數量固定，過的的consumer不能分配到messge queue。臨時編寫處理分發程序，從舊的topic快遞讀取到臨時的topic中，新的topic的queue數量擴容多倍，然後再啓動，更多的consumer進行臨時的新topic裏消費。
4.RocketMQ高性能的原因分析
MQ架構配置：
- 順序寫，隨機讀，零拷貝；
- 同步刷盤，異步刷盤，可根據選擇配置；
- 同步複製異步複製，可根據選擇配置（推進同步雙寫，異步刷盤）；
發送端高可用：
- 雙主雙從架構：創建多個topic的時候，MessageQueue創建在多個broker上，即相同的broker名稱，不同的brokerid(即主從模式)，當一個master不可用時，組內其他的master任然可用。但機器資源不足時，需要手工把slaver轉成master，目前不支持自動轉換，需要藉助shell腳本。
消費端高可用：
- 主從架構，Broker角色，master提供讀寫，slaver提供讀；
- Consumser不用配置，當master不可用或者繁忙的時候，Consumer會自動切換到Slaver節點進行讀取；
提供消息的消費能力：
- 並行消費：增加多個節點；增加多個Consumer的並行度，修改consuemrThreadMin和consumerThreadMax；批量消費，設置Consumer的consumerMessageMaxSize，默認是1，如果爲N,則消息多的時候，每次收到的消息爲N。
- 選擇linux Ext4文件系統，Ext4文件刪除1G大小的文件毫升小於50ms,而Ext3則要1s,刪除文件磁盤壓力大時，會導致IO超時。