消費端，一直不回傳 消費的結果。rocketmq認為消息沒收到，consumer下一次拉取，broker依然會發(fā)送該消息。
所以，任何異常都要捕獲返回ConsumeConcurrentlyStatus.RECONSUME_LATER
rocketmq會放到重試隊列。
這個重試TOPIC的名字是
%RETRY%+consumergroup的名字
在控制臺上過一會就可以查到。
重試的消息在延遲的某個時間點（默認是10秒，業(yè)務可設置）后，再次投遞到這個ConsumerGroup。而如果一直這樣重復消費都持續(xù)失敗到一定次數（默認16次），就會投遞到DLQ死信隊列，此時需要人工干預了。
/**
- Batch consumption size
*/
private int consumeMessageBatchMaxSize = 1;
/**
- Batch pull size
*/
private int pullBatchSize = 32;
consumeMessageBatchMaxSize 是批量消費的最大條數
pullBatchSize 是每次拉取的最大條數
在broker端的
private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";
參數是設置重試的時間，即第一次1s之后，第二次5s之后
為了測試，改成5s，生產環(huán)境不要改
messageDelayLevel = 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s
16次之后，多了一個topic
名為
%DLQ%+consumergroup
這個默認的16次，可以改。但是使用DefaultMQPullConsumer才可以修改。
DefaultMQPushConsumer不能修改此值。
順便再說下，consumeMessageBatchMaxSize 這個size是消費者注冊的回調listener一次處理的消息數，默認是1.不是每次拉取的消息數（默認是32），這個不要搞混。
