orderly：
1、SUSPEND_CURRENT_QUEUE_A_MOMENT：在本地重试，先判断重新消费次数有没有达到最大值(consumer定义的时候传入，不传为Integer最大值)，如果没达到，重试次数+1，放入消费池，1秒（默认）之后再消费，
直到达到最大消费次数。发送到重试队列（这个时候必然会进入死信队列，因为broker收到之后拿来比较的最大消费次数，也是consumer定义的时候传入的，是sendMessageBack方法，
用defaultMQPushConsumer.getMaxReconsumeTimes()取出来的）。所以用orderly消费，需要特别注意不要无限制重试的问题
2、上面讨论的是每批取出的消息数量是1的情况，如果每批取出数量大于1，SUSPEND_CURRENT_QUEUE_A_MOMENT这个状态代表的是当前批次的所有消息消费不成功，达到最大重试次数后，发送回重试队列，如果其中有一条没有发送成功，整批消息本地重试，
这种设计在极端情况下，也是没办法保证消息的有序性的。
concurrently：
3、在返回值是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默认的那样，无限制的消费的。
4、之所以可以延迟消费，是因为使用了delayTimeLevel这个属性，如果message的property这个标志大于0的话，broker收到消息，会放到RMQ_SYS_SCHEDULE_TOPIC这个topic中，ScheduleMessageService
定时取出，然后重新putMessage，放入正确topic--messageQueue中
5、上面讨论的，1-6中，1-3连续消费成功(或者成功发送回重试队列)，offset标记为3，先存在本地，再同步到远程关联到队列id+consumerGroup中，如果遇到20秒一次的rebalance，会从4重新拉取。所以这也是重复消费的一个原因，可见重复消费是无处不在的。
