有些场景，需要应用程序处理几种类型的消息，不同消息的优先级不同。RocketMQ是个先入先出的队列，不支持消息级别或者Topic级别的优先级。业务中简单的优先级需求，可以通过间接的方式解决，下面列举三种优先级相关需求的具体处理方法。
第一种：分开使用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的消费 。
转载地址：RocketMQ的消息优先级
