Orderly The Consumer will lock each MessageQueue to make sure it is consumed one by one in order. This will cause a performance loss, but it is useful when you care about the order of the messages. It is not recommended to throw exceptions, you can return ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT instead. 消費者將鎖定每個MessageQueue，以確保它按順序逐一消費。 這會導致性能損失，但在關心消息順序時非常有用。 不建議拋出異常，可以返回ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT。 注意，對于 consumer 而言，在暫時無法成功處理消息時，需要返回 ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT，這樣就會在一段時間之后重試消費消息。 SUSPEND_CURRENT_QUEUE_A_MOMENT 延緩多長時間執行，在當前隊列里 ~~~ else if ((this.consumeTimes.get() % 5) == 0) { context.setSuspendCurrentQueueTimeMillis(3000); return ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT; } ~~~ 4.本地消費的事務控制，ConsumeOrderlyStatus.SUCCESS（提交），ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT（掛起一會再消費），在此之前還有一個變量ConsumeOrderlyContext context的setAutoCommit()是否自動提交。 當SUSPEND_CURRENT_QUEUE_A_MOMENT時，autoCommit設置為true或者false沒有區別，本質跟消費相反，把消息從msgTreeMapTemp轉移回msgTreeMap，等待下次消費。 當SUCCESS時，autoCommit設置為true時比設置為false多做了2個動作，consumeRequest.getProcessQueue().commit()和this.defaultMQPushConsumerImpl.getOffsetStore().updateOffset(consumeRequest.getMessageQueue(), commitOffset, false); ProcessQueue.commit() ：本質是刪除msgTreeMapTemp里的消息，msgTreeMapTemp里的消息在上面消費時從msgTreeMap轉移過來的。 this.defaultMQPushConsumerImpl.getOffsetStore().updateOffset() ：本質是把拉消息的偏移量更新到本地，然后定時更新到broker。 那么少了這2個動作會怎么樣呢，隨著消息的消費進行，msgTreeMapTemp里的消息堆積越來越多，消費消息的偏移量一直沒有更新到broker導致consumer每次重新啟動后都要從頭開始重復消費。 就算更新了offset到broker，那么msgTreeMapTemp里的消息堆積呢？不知道這算不算bug。 所以，還是把autoCommit設置為true吧。 當使用順序消費的回調MessageListenerOrderly時，由于順序消費是要前者消費成功才能繼續消費，所以沒有RECONSUME_LATER的這個狀態，只有SUSPEND_CURRENT_QUEUE_A_MOMENT來暫停隊列的其余消費，直到原消息不斷重試成功為止才能繼續消費。