RocketMQ常见问题及解决方案-Toy模板网

这篇具有很好参考价值的文章主要介绍了RocketMQ常见问题及解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

RocketMQ FAQ

1、消费组的消息的消费状态为NOT_CONSUME_YET

可能原因

1）消费端处理消息发生异常没有捕获或是因为其他原因，没有返回消费状态

解决方案：

消费端捕获异常，

如果需要重试，返回ConsumeConcurrentlyStatus.RECONSUME_LATER，

如果不需要重试，返回ConsumeConcurrentlyStatus.RECONSUME_SUCCESS

可以在消费端增加重试次数判断，例如重试三次就返回成功

if (msgs.get(0).getReconsumeTimes() == 3) {

// 该条消息可以存储到DB或者LOG日志中，或其他处理方式

return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;// 成功

} else {

return ConsumeConcurrentlyStatus.RECONSUME_LATER;// 重试

}

2）不同的消费者consumer1,、consumer2配置了相同的单个消费组consumerGroup，订阅了多个topic和tags，此种场景下，消费端初始化消费者后，consumer1和consumer2与broker建立心跳连接是，会相互覆盖相同consumerGroup下消费的topic信息，导致部分消息消费不了

解决方案：

建议一个消费组订阅一个topic

若非要一个消费组定于多个topic，也只能初始化一个消费者实例，订阅多个topic和tags组合

eg ：

DefaultMQPushConsumerconsumer = new DefaultMQPushConsumer("test_group", "secretId", "secretKey");

consumer.subscribe("topicA", "tagA||tagA1");

consumer.subscribe("topicB", "tagB||tagB1");

2、消息堆积

可能原因

1、消费消息速度赶不上生产消息速度

解决方案

消费速度慢的处理方式

1 提高消费并行度

绝大部分消息消费行为都属于 IO 密集型，即可能是操作数据库，或者调用 RPC，这类消费行为的消费速度在于后端数据库或者外系统的吞吐量，通过增加消费并行度，可以提高总的消费吞吐量，但是并行度增加到一定程度，反而会下降。所以，应用必须要设置合理的并行度。如下有几种修改消费并行度的方法：

同一个 ConsumerGroup 下，通过增加 Consumer 实例数量来提高并行度（需要注意的是超过订阅队列数的 Consumer 实例无效）。可以通过加机器，或者在已有机器启动多个进程的方式。

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

2 批量方式消费

某些业务流程如果支持批量方式消费，则可以很大程度上提高消费吞吐量，例如订单扣款类应用，一次处理一个订单耗时 1 s，一次处理 10 个订单可能也只耗时 2 s，这样即可大幅度提高消费的吞吐量，通过设置 consumer的 consumeMessageBatchMaxSize 返个参数，默认是 1，即一次只消费一条消息，例如设置为 N，那么每次消费的消息数小于等于 N。

3 跳过非重要消息

发生消息堆积时，如果消费速度一直追不上发送速度，如果业务对数据要求不高的话，可以选择丢弃不重要的消息。例如，当某个队列的消息数堆积到100000条以上，则尝试丢弃部分或全部消息，这样就可以快速追上发送消息的速度。示例代码如下：

public ConsumeConcurrentlyStatus consumeMessage(

    List<MessageExt> msgs,

    ConsumeConcurrentlyContext context) {

    long offset = msgs.get(0).getQueueOffset();

    String maxOffset =

    msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET);

    long diff = Long.parseLong(maxOffset) - offset;

    if (diff > 100000) {

        // TODO 消息堆积情况的特殊处理

        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;

    }

    // TODO 正常消费过程

    return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;

}

4 优化每条消息消费过程

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

根据消息从 DB 查询【数据 1】

根据消息从 DB 查询【数据 2】

复杂的业务计算

向 DB 插入【数据 3】

向 DB 插入【数据 4】

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