orderly：
SUSPEND_CURRENT_QUEUE_A_MOMENT：在本地重试，先判断重新消费次数有没有达到最大值(consumer定义的时候传入，不传为Integer最大值)，如果没达到，重试次数+1，放入消费池，1秒（默认）之后再消费，
直到达到最大消费次数。发送到重试队列（这个时候必然会进入死信队列，因为broker收到之后拿来比较的最大消费次数，也是consumer定义的时候传入的，是sendMessageBack方法，
用defaultMQPushConsumer.getMaxReconsumeTimes()取出来的）。所以用orderly消费，需要特别注意不要无限制重试的问题
concurrently：
在返回值是CONSUME_SUCCESS的时候，广播模式是不管消费成功与否的，集群模式下，一批消息中，可以在context中，标记消费成功到第几个(ackIndex，RECONSUME_LATER的ackIndex为-1，意味着所有都是失败的)，
之后的就是消费失败的，这些失败的，如果能发送回重试队列，也视为消费成功(重试次数会+1)，否则就提交到线程池中，5秒(注意这里和orderly不同)后再消费。至于offstore中确认的offset，比如1-6条消息，
消费了1、2、3、5，offset就是3，连续的最大值。但是pullResult中的，会是7，往后面拉取。还要注意的是，这里发回给重试队列，不是用的orderly的send方法，而是consumerSendMessageBack方法，
这个方法里会自定义最大重试次数为16，所以这个时候如果一直消费不成功，是不会像orderly默认的那样，无限制的消费的。
之所以可以延迟消费，是因为使用了delayTimeLevel这个属性，如果message的property这个标志大于0的话，broker收到消息，会放到RMQ_SYS_SCHEDULE_TOPIC这个topic中，ScheduleMessageService
定时取出，然后重新putMessage，放入正确topic--messageQueue中