全网最深入的RocketMQ Consumer 学习笔记

消费模式

消息消费有两种模式：

 

1、并发消费

并发消费是默认的处理方法，一个消费者使用线程池技术，可以并发消费多条消息，提升机器的资源利用率。默认配置是 20 个线程，所以一台机器默认情况下，同一瞬间可以消费 20 个消息。

其中 ConsumeMessageConcurrentlyService 的构造函数如下：

public ConsumeMessageConcurrentlyService(DefaultMQPushConsumerImpl defaultMQPushConsumerImpl,
        MessageListenerConcurrently messageListener) {
        this.defaultMQPushConsumerImpl = defaultMQPushConsumerImpl;
        this.messageListener = messageListener;
        this.defaultMQPushConsumer = this.defaultMQPushConsumerImpl.getDefaultMQPushConsumer();
        this.consumerGroup = this.defaultMQPushConsumer.getConsumerGroup();
        this.consumeRequestQueue = new LinkedBlockingQueue<Runnable>();
        this.consumeExecutor = new ThreadPoolExecutor(
            this.defaultMQPushConsumer.getConsumeThreadMin(),
            this.defaultMQPushConsumer.getConsumeThreadMax(),
            1000 * 60,
            TimeUnit.MILLISECONDS,
            this.consumeRequestQueue,
            new ThreadFactoryImpl("ConsumeMessageThread_"));
        this.scheduledExecutorService = Executors.newSingleThreadScheduledExecutor(new ThreadFactoryImpl("ConsumeMessageScheduledThread_"));
        this.cleanExpireMsgExecutors = Executors.newSingleThreadScheduledExecutor(new ThreadFactoryImpl("CleanExpireMsgScheduledThread_"));
    }

2、顺序消费

有些业务场景，消息的消费需要顺序性，例如购物时，下订单、库存校验、支付、发送物流，虽然都属于「购物」这个场景的子任务，但他们之间是有顺序性的。如果它们业务处理通过消息解耦，那消息消费也得要有顺序性。

RocketMQ 的做法就是分区有序性，首先需要发送者，将有顺序的消息发往 Topic 下同一个 MessageQueue，然后消费者，顺序地一个一个进行消费，消费失败将会一直重试，前面消息消费完成才能进行下一个，所以需要在业务上确保消息失败机制，避免消息阻塞。

 

---

幂等消费

在 RocketMQ 的设计中，是不保证消息的幂等性，这时候需要业务方自行保证，重复消费消费不会对数据造成影响，从数学意义上来说，f(x) = f(f(x))，多次计算的结果都是一致的。

RocketMQ 保证存储在 Broker 的消息最少投递一次，该特性保证消息一定会被消费，但由于网络抖动或者其它场景，导致一条消息可能被消费多次。

在相同业务类型的消息中，这里需要考虑两个场景

• 并发消费
• 消息消费超时后重复投递

第一个场景很好理解，一条相同类型的消息被不同的消费者同时拉取，可能是不同发送者同时发送的，例如喜闻乐见的 A B 转账问题。

第二个场景比较难遇到，默认情况，消息处理超过 15 分钟后，将会重新投递消费，如果原来服务器 A 还在处理中，重新投递的消息被服务器 B 拉取了；另一种就是手动重发消息，通过控制台可以重新发送一模一样的消息，MessageID 和消息体跟之前一样，这两种情况下也会造成消息重复消费。

于是设计上，考虑了使用 Redis 做分布式锁，通过竞争锁来避免同时消息，以及用 Redis 暂存消费状态，设计如下：

<