messageModel有两种方式：BROADCASTING 和 CLUSTERING，
消费者收到消息也有两种消费方式：orderly和concurrently，
1、BROADCASTING模式下，所有注册的消费者都会消费，而这些消费者通常是集群部署的一个个微服务，这样就会多台机器重复消费。
2、在CLUSTERING模式下，如果一个topic被多个consumerGroup消费，也会重复消费。
3、即使是在CLUSTERING模式下，同一个consumerGroup下，一个队列只会分配给一个消费者，看起来好像是不会重复消费。但是，有个特殊情况：一个消费者上线后，同组的所有消费者要重新负载均衡（反之一个消费者掉线后，也一样）。一个队列所对应的新的消费者要获取之前消费的offset，此时之前的消费者可能已经消费了一条消息，但是并没有把offset提交给broker，那么新的消费者可能会重新消费一次。虽然orderly是前一个消费者先解锁，后一个消费者加锁再消费的模式，比起concurrently要严格了，但是加锁的线程和提交offset的线程不是同一个，所以还是会出现极端情况下的重复消费。
4、默认情况下orderly和concurrently模式都是一条一条的消费，但是如果在消费一条消息的时候要进行比如AB两个操作，在没有事务控制的情况下，如果A操作成功而B操作失败，就会重新消费导致A操作会再执行一次，这样虽然不是重复的消费整条消息，但是一部分的操作会重复。如果放宽条件到一次消费多条的情况，orderly模式是一批中有一条消费失败，一批统一重新消费，直到达到最大消费次数的限制，发送到死信队列。而concurrently情况下，在返回成功(CONSUME_SUCCESS)的前提下，有个ackIndex可以分隔成功和失败的消息，失败的、没有消费的消息发送到retry队列，不会造成重复消费，而如果返回的是(RECONSUME_LATER)，仍然是和orderly一样的同批次全部重新消费。（其实orderly也可以这样做，但是不知道为什么没有，而是全部重新放入队列消费）。
5、消费者pullRequest发出去，如果长时间收不到请求，是会被取出来重新再放入队列再请求一次的，所以也是会重复拉取消息的。
注：orderly和concurrently消费失败的处理（假设在集群模式下）：
ConsumeMessageOrderlyService的内部类ConsumeRequest的run方法中，messageListener.consumeMessage的返回值status的值有两种：SUSPEND_CURRENT_QUEUE_A_MOMENT和 SUCCESS，如果抛出异常返回null，随后仍会被赋值SUSPEND_CURRENT_QUEUE_A_MOMENT，接下来的processConsumeResult方法中，在isAutoCommit为true的判断中，进入SUSPEND_CURRENT_QUEUE_A_MOMENT的判断，假设把msgs的size简化为1（也就是说一次只从processQueue的msgTreeMap中取出offset最小的那条），默认的maxReconsumeTimes是Integer.maxValue，一般是需要自己设置一次的，到达最大失败次数，还是没成功，进入sendMessageBack方法，在调用send方法发送消息，看起来是把消息发送到topic为retry开头的重试队列，但是，由于broker这里SendMessageProcessor.sendMessage方法中，有handleRetryAndDLQ方法判断当前消息的重试次数有没有达到最大重试次数，如果到达，替换topic为DLQ死信队列，将消息存储到死信队列中。刚才说的是每次从processQueue获取一条消息的情况，如果一次获取多条，那么如果status不是成功，那么会针对每一条消息判断是不是到达最大重试次数，如果到达，送到死信队列，如果没有，重试次数加一，再次放到processQueue中。而这次成功消费的offset要保存，因为之前的前提是集群模式，那么要提交给messageId对应的broker，具体代码逻辑是：RemoteBrokerOffsetStore的updateOffset是存到自己的offsetTable属性中，而MQClientInstance.start---startScheduledTask---persistAllConsumerOffset---RemoteBrokerOffsetStore.persistAll---updateConsumeOffsetToBroker，把offset提交。
而ConsumeMessageConcurrentlyService的submitConsumeRequest方法，把这次取到的消息分批（如果需要的话），组装成内部类ConsumeRequest，所以concurrently也存在一次消费多条消息的情况，这时候会在context参数中保存一个ackIndex，如果成功了，ackIndex不变，如果失败了，ackIndex为-1，如果ackIndex小于这次分批msgs的size，那么之后的消息要发送回重试队列，这里和orderly不同，orderly是直接send方法，而这里的requestCode都不一样了。这里也会判断最大消费次数的问题，发送到重试队列或者死信队列。注意和orderly不同的是，orderly是本地重试，不会发送到重试队列，只会最后发送到死信队列。而concurrently会先发送到重试队列。至于本地消息的删除以及commitoffset的处理，因为并发消费在目前的业务中不太能用得到，等以后用到了再看。