RocketMQ消费者

1消费过程幂等

RocketMQ无法避免消息重复(Exactly-Once)，所以如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。

可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是msgld，也可以是消息内容中的唯一标识字段，例如订单ld等。

在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。(实际过程要考虑原子性问题，判断是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过)

msgld一定是全局唯一标识符，但是实际使用中，可能会存在相同的消息有两个不同msgld的情况(消费者主动重发、因客户端重投机制导致的重复等)，这种情况就需要使业务字段进行重复消费。

2消费速度慢的处理方式

提高消费并行度

绝大部分消息消费行为都属于10密集型，即可能是操作数据库，或者调用RPC，这类消费行为的消费速度在于后端数据库或者外系统的吞吐量。

通过增加消费并行度，可以提高总的消费吞吐量，但是并行度增加到一定程度，反而会下降。

所以，应用必须要设置合理的并行度。如下有几种修改消费并行度的方法：

●同一个ConsumerGroup下，通过增加Consumer实例数量来提高并行度(需要注意的是超

过订阅队列数的Consumer实例无效)。可以通过加机器，或者在已有机器启动多个进程的

方式。

●提高单个Consumer的消费并行线程，通过修改参数consumeThreadMin、consumeThreadMax实现。

●丢弃部分不重要的消息

批量方式消费

某些业务流程如果支持批量方式消费，则可以很大程度上提高消费吞吐量。

例如订单扣款类应用，一次处理一个订单耗时1 s，一次处理10个订单可能也只耗时2s，这样即可大幅度提高消费的吞吐量，通过设置consumer的consumeMessageBatchMaxSize返个参数，默认是1，即一次只消费一条消息，例如设置为N，那么每次消费的消息数小于等于N。

跳过非重要消息

发生消息堆积时，如果消费速度一直追不上发送速度，如果业务对数据要求不高的话，可以选择丢弃不重要的消息。

例如，当某个队列的消息数堆积到10000条以上，则尝试丢弃部分或全部消息，这样就可以快速追上发送消息的速度。示例代码如下：

public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,consumeConcurrentlyContext context) {

    long offset = msgs.get(0).getQueue0ffset();
    String maxoffset = msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET); 

    1ong diff = Long.parseLong(maxoffset) - offset;
    if (diff > 100000) {
        // TODO消息堆积情况的特殊处理
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        //TODO正常消费过程
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}

3优化每条消息消费过程

举例如下，某条消息的消费过程如下：

●根据消息从DB查询[数据1]

●根据消息从DB查询[数据2]

●复杂的业务计算

●向DB插入[数据3]

●向DB插入[数据4]

这条消息的消费过程中有4次与DB的交互，如果按照每次5ms计算，那么总共耗时20ms，假设业务计算耗时5ms，那么总过耗时25ms，所以如果能把4次DB交互优化为2次，那么总耗时就可以优化到15ms，即总体性能提高了40%。所以应用如果对时延敏感的话，可以把DB部署在SSD硬盘，相比于SCSI磁盘，前者的RT会小很多。

4消费打印日志

如果消息量较少，建议在消费入口方法打印消息，消费耗时等，方便后续排查问题。

如果能打印每条消息消费耗时，那么在排查消费慢等线上问题时，会更方便。

public ConsumeConcurrentlystatus consumeMessage(List<MessageExt> msgs,ConsumeConcurrentlyContext context){

    log.info("RECEIVE_MSG_BEGIN:" + msgs.tostring());
    // TODO 正常消费过程

    return ConsumeConcurrentlystatus.CONSUME_SUCCESS;
}

5其他消费建议

(1)关于消费者和订阅

第一件需要注意的事情是，不同的消费组可以独立的消费一些topic，并且每个消费组都有自己的消费偏移量。

确保同一组内的每个消费者订阅信息保持一致。

(2)关于有序消息

消费者将锁定每个消息队列，以确保他们被逐个消费，虽然这将会导致性能下降，但是当你关心消息顺序的时候会很有用。

我们不建议抛出异常，你可以返回

ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT作为替代。

(3)关于并发消费

顾名思义，消费者将并发消费这些消息，建议你使用它来获得良好性能，我们不建议抛出异常，你可以返回ConsumeConcurrentlyStatus.RECONSUME_LATER作为替代。

(4)关于消费状态Consume Status

对于并发的消费监听器，你可以返回RECONSUME_LATER来通知消费者现在不能消费这条消息，并且希望可以稍后重新消费它。然后，你可以继续消费其他消息。对于有序的消息监听器，因为你关心它的顺序，所以不能跳过消息，但是你可以返回SUSPEND_CURRENT.QUEUE_A_MOMENT告诉消费者等待片刻。

(5)关于Blocking

不建议阻塞监听器，因为它会阻塞线程池，并最终可能会终止消费进程

(6)关于线程数设置

消费者使用ThreadPoolExecutor在内部对消息进行消费，所以你可以通过设置

setConsumeThreadMin或setConsumeThreadMax来改变它。

(7)关于消费位点

当建立一个新的消费组时，需要决定是否需要消费经存在于Broker中的历史消息。

CONSUME_FROM_LAST_OFFSET将会忽略历史消息，并消费之后生成的任何消息。

CONSUME_FROM_FIRST_OFFSET将会消费每个存在于Broker中的信息。

也可以使用CONSUME_FROM TIMESTAMP来消费在指定时间戳后产生的消息。

public static void main(String[] args) throws MQClientException {
    DefaultMQPushConsumer consumer = new DefaultMQPushconsumer("consumer_grp_15_01");
    consumer.setNamesrvAddr("node1: 9988");
    consumer.subscribe("sl_demo_18"，"*");
    //以下三个选一个使用，如果是根据时间戳进行消费，则需要设置时间戳
    //从第一个消息开始消费，从头开始
    consumer.setConsumeFromwhere(ConsumeFromwhere.CONSUME_FROM_FIRST_OFFSET);
    //从最后一个消息开始消费，不消费历史消息
    consumer.setConsumeFromwhere(ConsumeFromwhere.CONSUME_FROM_LAST_OFFSET);
    //从指定的时间戳开始消费
    consumer.setConsumeFromwhere(ConsumeFromwhere.CONSUME_FROM_TIMESTAMP);
    //指定时间戳的值
    consumer.setConsumeTimestamp("");

    consumer.setMessageListener(new MessageListenerConcurrently() {
        @override
        public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {

            // TODO 处理消息的业务逻辑
            return ConsumeConcurrentlystatus.CONSUME_SUCCESS;
            //    return ConsumeConcurrentlyStatus.RECONSUME.LATER;
    });

    consumer.start();
}