Rocket順序消息的最佳實踐是怎樣的

順序消息

順序消息缺陷

發送順序消息無法利用集群Fail Over特性消費，順序消息的并行度依賴于隊列數量，存在隊列熱點問題，個別隊列由于哈希不均導致消息過多，消費速度跟不上，產生消息堆積問題遇到消息失敗的消息，無法跳過，當前隊列消費暫停。

原理

produce在發送消息的時候，把消息發到同一個隊列（queue）中,消費者注冊消息監聽器為MessageListenerOrderly，這樣就可以保證消費端只有一個線程去消費消息。
注意：把消息發到同一個隊列（queue），不是同一個topic，默認情況下一個topic包括4個queue 

擴展

可以通過實現發送消息的隊列選擇器方法，實現部分順序消息。
舉例：比如一個數據庫通過MQ來同步，只需要保證每個表的數據是同步的就可以。解析binlog，將表名作為隊列選擇器的參數，這樣就可以保證每個表的數據到同一個隊列里面，從而保證表數據的順序消費。 

最佳實踐 

Producer

• Topic
  一個應用盡可能用一個Topic，消息子類型用tags來標識，tags可以由應用自由設置。只有發送消息設置了tags，消費方在訂閱消息時，才可以利用tags 在broker做消息過濾。

• key
  每個消息在業務層面的唯一標識碼，要設置到 keys 字段，方便將來定位消息丟失問題。服務器會為每個消息創建索引(哈希索引)，應用可以通過 topic，key來查詢這條消息內容，以及消息被誰消費。由于是哈希索引，請務必保證key 盡可能唯一，這樣可以避免潛在的哈希沖突。

  
  

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

• 日志
  消息發送成功或者失敗，要打印消息日志，務必要打印 send result 和key 字段。

• send
send消息方法，只要不拋異常，就代表發送成功。但是發送成功會有多個狀態，在sendResult里定義。
  SEND_OK：消息發送成功
  FLUSH_DISK_TIMEOUT：消息發送成功，但是服務器刷盤超時，消息已經進入服務器隊列，只有此時服務器宕機，消息才會丟失
  FLUSH_SLAVE_TIMEOUT：消息發送成功，但是服務器同步到Slave時超時，消息已經進入服務器隊列，只有此時服務器宕機，消息才會丟失
  SLAVE_NOT_AVAILABLE：消息發送成功，但是此時slave不可用，消息已經進入服務器隊列，只有此時服務器宕機，消息才會丟失

Consumer

• 冪等
  RocketMQ使用的消息原語是At Least Once，所以consumer可能多次收到同一個消息，此時務必做好冪等。

• 日志
  消費時記錄日志，以便后續定位問題。

• 批量消費
  盡量使用批量方式消費方式，可以很大程度上提高消費吞吐量。