RocketMQ源码学习 (十四) 顺序消费服务原理

1 引文

之前的内容里学习了rocketMQ的消费者并发消费的相关原理和源码，本篇文章开始学习顺序消费的相关原理。
首先，什么是顺序消费？，在一个queue里面，消息需要按照FIFO的规则，RocketMQ不支持全局顺序消费，只支持在一个主题下的一个queue队列是有序的，如果想要做到全局顺序消费该怎么办呢？设置只有一个queue就可以了，但是这样性能很低。并发消费不能支持顺序消费，并发消费中Rebalance分配队列给当前消费者，这个阶段分配的队列不能保证同时只有该消费者被消费，几个消费者同时消费一个队列就不能讲顺序这件事，要保证顺序消费，就必须保证一个队列在全局内同一时刻只能有一个消费者在消费。
RocketMQ的顺序消费的前提：

1. queue必须加锁，加在broker的分布式锁，在broker中有个 Map<group@topic, Map<int(queue), Entry>>，这里面的Entry就是锁记录，记录了这把锁的归属，续约时间，当获取到锁的时间就是续约时间，如果客户端续约时间在60s以内则还持有该锁，超过60s则其他消费者就可以拿到这把锁了；
2. 消费者本地必须保证同一时间只能有一个消费任务(一个消费任务就是对应一个线程)在执行消费任务。
   在说完这个前提之后，就开启本文的学习之旅。

2 doRebalance的逻辑

在下图中，如果PQ(ProcessQueue)获取到锁成功，如果当时PQ的treeMap为Empty，不会延迟20秒，直接释放锁，如果不是Empty则会延迟20秒再释放锁，为什么要延迟20秒呢？保证全局范围内同时只能有一个消费任务，如果立刻释放锁，消费任务还没完全退出任务，其他节点有可能拿到这把锁，这样全局就会有两个消费任务去消费这个queue。
顺序消费和并发消费不一样，顺序消费是从服务器pull下来后将msg存到msgTreeMap，存的时候会检查PQ的consuming的状态是否是消费中，为false说明消费者这里没有消费任务在运行，将这条msg添加进去之后会将其改成t