RocketMQ消息优先级

有些场景，需要应用程序处理几种类型的消息，不同消息的优先级不同。RocketMQ是个先入先出的队列，不支持消息级别或者Topic级别的优先级。业务中简单的优先级需求，可以通过间接的方式解决，下面列举三种优先级相关需求的具体处理方法。

第一种

多个不同的消息类型使用同一个topic时，由于某一个种消息流量非常大，导致其他类型的消息无法及时消费，造成不公平，所以把流量大的类型消息在一个单独的Topic，其他类型消息在另外一个Topic，应用程序创建两个Consumer，分别订阅不同的Topic，这样就可以了。

第二种

情况和第一种情况类似，但是不用创建大量的Topic举个实际应用场景: 一个订单处理系统，接收从100家快递门店过来的请求，把这些请求通过Producer写入RocketMQ；订单处理程序通过Consumer从队列里读取消息并处理，每天最多处理1万单。如果这100个快递门店中某几个门店订单量大增，比如门店一接了个大客户，一个上午就发出2万单消息请求，这样其他的99家门店可能被迫等待门店的2万单处理完，也就是两天后订单才能被处理，显然很不公平。

这时可以创建一个Topic，设置Topic的MessageQueue数量超过100个，Producer根据订单的门店号，把每个门店的订单写人一个MessageQueue。DefaultMQPushConsumer默认是采用循环的方式逐个读取一个Topic的所有MessageQueue，这样如果某家门店订单量大增，这家门店对应的MessageQueue消息数增多，等待时间增长，但不会造成其他家门店等待时间增长。

DefaultMQPushConsumer默认的pullBatchSize是32，也就是每次从某个MessageQueue读取消息的时候，最多可以读32个。在上面的场景中，为了更加公平，可以把pullBatchSize设置成1。

第三种

强制优先级

TypeA、TypeB、TypeC三类消息。TypeA处于第一优先级，要确保只要有TypeA消息，必须优先处理；TypeB处于第二优先级；TypeC处于第三优先级。对这种要求，或者逻辑更复杂的要求，就要用户自己编码实现优先级控制，如果上述的三类消息在一个Topic里，可以使用PullConsumer，自主控制MessageQueue的遍历，以及消息的读取；如果上述类消息在三个 Topic下，需要启动三个Consumer，实现逻辑控制三个Consumer的消费。