【RocketMQ】RocketMQ应用难点

🎯 导读：本文探讨了RocketMQ中消息重复消费的问题及其解决方案，尤其是在CLUSTERING模式下的扩容影响。文章分析了重复消费的原因，如广播模式、负载均衡模式下的多consumerGroup消费、消费者组内的动态变化及网络延迟等，并提出了利用唯一标识进行去重的方法。此外，还讨论了如何选择合适的存储机制以高效处理大量消息标识，如HashMap、MySQL、Redis以及推荐的布隆过滤器等方案。对于防止消息堆积与确保消息不丢失，也给出了相应的策略和技术措施。

消息重复消费问题（去重）

为什么出现重复消费

官网说明：RocketMQ确保所有消息至少传递一次。在大多数情况下，消息不会重复。

• BROADCASTING（广播）模式下，所有注册的消费者都会消费，这些消费者通常是集群部署的一个个微服务，这样就会多台机器重复消费
• CLUSTERING（负载均衡）模式下，如果一个topic被多个consumerGroup消费，也会重复消费
• 扩容影响：在 CLUSTERING 模式下，只有一个 consumerGroup ，一个队列只会分配给一个消费者，看起来好像是不会重复消费。但有个特殊情况：一个消费者新上线后，同组的所有消费者要重新负载均衡（反之，一个消费者掉线后也一样）。一个队列所对应的新的消费者要获取之前消费的offset，可能此时之前的消费者已经消费了一条消息，但并没有把 offset 提交给broker，那么新的消费者可能会重新消费一次。虽然orderly模式是前一个消费者先解锁，后一个消费者加锁再消费的模式，比起concurrently要严格了，但是加锁的线程和提交offset的线程不是同一个，所以还是会出现极端情况下的重复消费
• 在发送批量消息的时候，会被当做一条消息进行处理，那么如果批量消息中有一条业务处理成功，其他失败了，还是会被重新消费一次
• 网络卡顿，生产者多次发一样的消息（例如买一个东西，发送了两次减库存）

【扩容影响说明】

一开始只有一个消费者，4个队列都归C1管，C1已经开始消费a、b、c、d了，但是还没有消费完，没有返回让offset偏移

突然C2上线了，看到 c、d 还没有被消费完，然后自己又拿去消费一次

那么如果在CLUSTERING（负载均衡）模式下，并且在同一个消费者组中，不希望一条消息被重复消费，该怎么办呢？我们可以想到去重操作，找到消息唯一的标识，可以是msgId，也可以是你自定义的唯一的key，

解决方案

官网：RocketMQ 无法避免消息重复(Exactly-Once)，所以如果业务对消费重复非常敏感，务必在业务层面进行去重处理。可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是 msgld，也可以是消息内容中的唯一标识字段，例如订单 id 等。在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。(实际过程要考虑原子性问题，判断不存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过)

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

使用去重方案解决，例如将消息的唯一标识存起来，然后每次消费之前先判断是否存在这个唯一标识，如果存在则不消费，如果不存在则消费，并且消费以后将这个标记保存。消息的体量是非常大的，可能在生产环境中会到达上千万甚至上亿条，那么我们该如何选择一个容器来保存所有消息的标识，并且又可以快速的判断是否存在呢？

• HashMap：单机部署可以使用，无法解决分布式问题
• MySQL去重表，加唯一索引，插入成功就执行业务：太慢了，数据库压力大
• Redis(setnx)：占用内存大，成本高
• 布隆过滤器（推荐）：内存小，效率高

MySQL去重

@SpringBootTest
class ARocketmqDemoApplicationTests {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Test
    void repeatProducer() throws Exception {
        DefaultMQProducer producer = new DefaultMQProducer("repeat-producer-group");
        producer.setNamesrvAddr(MqConstant.NAME_SRV_ADDR);
        producer.start();
        String key = UUID.randomUUID().toString();
        System.out.println(key);
        // 测试 发两个key一样的消息
        Message m1 = new Message("repeatTopic", null, key, "扣减库存-1".getBytes());
        Message m1Repeat = new Message("repeatTopic", null, key, "扣减库存-1".getBytes());
        producer.send(m1);
        producer.send(m1Repeat);
        System.out.println("发送成功");
        producer.shutdown();
    }

    /**
     * mysql的唯一索引实现消费幂等性
     * ---------------------
     * 我们设计一个去重表 对消息的唯一key添加唯一索引
     * 每次消费消息的时候 先插入数据库 如果成功则执行业务逻辑 [如果业务逻辑执行报错 则删除这个去重表记录]
     * 如果插入失败 则说明消息来过了,直接签收了
     *
     * @throws Exception
     */
    @Test
    void repeatConsumer() throws Exception {
        DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("repeat-consumer-group");
        consumer.setNamesrvAddr(MqConstant.NAME_SRV_ADDR);
        consumer.subscribe("repeatTopic", "*");
        consumer.registerMessageListener(new MessageListenerConcurrently() {
            @Override
            public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
                // 先拿key
                MessageExt messageExt = msgs.get(0);
                String keys = messageExt.getKeys();
                // 原生方式操作
                Connection connection = null;
                try {
                    connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/test?serverTimezone=GMT%2B8&useSSL=false", "root", "123456");
                } catch (SQLException e) {
                    e.printStackTrace();
                }
                PreparedStatement statement = null;

                try {
                    // 插入数据库 因为我们 key做了唯一索引
                    statement = connection.prepareStatement("insert into order_oper_log(`type`, `order_sn`, `user`) values (1,'" + keys + "','123')");
                } catch (SQLException e) {
                    e.printStackTrace();
                }

                // 新增 要么成功 要么报错   修改 要么成功,要么返回0 要么报错
                try {
                    // 执行新增
                    statement.executeUpdate();
                } catch (SQLException e) {
                    System.out.println("executeUpdate");
                    if (e instanceof SQLIntegrityConstraintViolationException) {
                        // 唯一索引冲突异常
                        // 说明消息来过了
                        System.out.println("该消息来过了");
                        // 签收消息，从队列中删除消息
                        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
                    }
                    e.printStackTrace();
                }

                // 如果业务报错 则删除掉这个去重表记录 delete order_oper_log where order_sn = keys;
                // 不删除的话，每次重试就会报错，重试失败
                System.out.println(new String(messageExt.getBody()));
                System.out.println(keys);
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
        });
        consumer.start();
        System.in.read();
    }

}

布隆过滤器

布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。

在hutool的工具中我们可以直接使用，使用redis的bitmap类型手写一个也可以的，Redisson中也有布隆过滤器的实现 https://hutool.cn/docs/#/bloomFilter/%E6%A6%82%E8%BF%B0

• 布隆过滤器判断key不在，说明消息没有被消费过，执行消费
• 布隆过滤器判断key存在，消息可能被消费过，需要做进一步判断（可以结合MySQL做进一步判断）

加锁（适合短时间的去重）

• 添加一个限时锁
• 如果可以加锁成功，执行消费，消费失败，释放锁；如果加锁失败，说明消息被消费了，或者正在消费中，直接返回即可，后续如果消费失败，消息会被再次投递

过程

• 生产者发消息带唯一标记
• 消费者控制消息消费幂等性（多次操作的影响均和第一次操作产生的影响相同）
  • 方式一：查询key是否存在（存在就返回、不存在就新增并执行业务）
  • 方式二：直接插入（插入成功就执行业务，否则返回）

那些操作需要控制幂等

新增：普通的新增操作是非幂等的（字段有唯一约束除外）

修改：看情况（++不是幂等，i=i+1是幂等）

查询：幂等操作

删除：幂等操作

布隆过滤器实现

生产者

@Test
public void testRepeatProducer() throws Exception {
    // 创建默认的生产者
    DefaultMQProducer producer = new DefaultMQProducer("test-group");
    // 设置nameServer地址
    producer.setNamesrvAddr("localhost:9876");
    // 启动实例
    producer.start();
    // 我们可以使用自定义key当做唯一标识
    String keyId = UUID.randomUUID().toString();
    System.out.println(keyId);
    Message msg = new Message("TopicTest", "tagA", keyId, "我是一个测试消息".getBytes());
    SendResult send = producer.send(msg);
    System.out.println(send);
    // 关闭实例
    producer.shutdown();
}

添加 hutool 的依赖

<dependency>
    <groupId>cn.hutool</groupId>
    <artifactId>hutool-all</artifactId>
    <version>5.7.11</version>
</dependency>

消费者

/**
 * 在boot项目中可以使用@Bean在整个容器中放置一个单例对象
 */
public static BitMapBloomFilter bloomFilter = new BitMapBloomFilter(100);
 
@Test
public void testRepeatConsumer() throws Exception {
    // 创建默认消费者组
    DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("consumer-group");
    consumer.setMessageModel(MessageModel.BROADCASTING);
    // 设置nameServer地址
    consumer.setNamesrvAddr("localhost:9876");
    // 订阅一个主题来消费   表达式，默认是*
    consumer.subscribe("TopicTest", "*");
    // 注册一个消费监听 MessageListenerConcurrently是并发消费
    // 默认是20个线程一起消费，可以参看 consumer.setConsumeThreadMax()
    consumer.registerMessageListener(new MessageListenerConcurrently() {
        @Override
        public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
                                                        ConsumeConcurrentlyContext context) {
            // 拿到消息的key
            MessageExt messageExt = msgs.get(0);
            String keys = messageExt.getKeys();
            // 判断是否存在布隆过滤器中
            if (bloomFilter.contains(keys)) {
                // 执行进一步的精确判断
                boolean isConsumed = MySQL查询(keys);
                if (isConsumed == true) return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
            执行业务处理（假如执行完业务，宕机了，key没有被添加到布隆过滤器中，还是重复消费）
            bloomFilter.add(keys);
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        }
    });
    consumer.start();
    System.in.read();
}

上面的方案已经可以解决绝大多数的重复消费问题了，像宕机这种极端场景，我还不知道完美的解决方案，有知道的大佬请告诉我，谢谢

如何解决消息堆积问题？

一般认为单条队列消息差值>=10w时算消息堆积

什么情况下会出现堆积

生产速度 远大于 消费速度

• 生产方可以做业务限流

• 增加消费者数量，但是消费者数量<=队列数量，适当增加消费线程数量

  

  • @RocketMQMessageListener(topic = "modeTopic",
     consumerGroup = "mode-consumer-group-a", 
     messageModel = MessageModel.CLUSTERING, 
     consumeThreadNumber = 40)
    public class MyConsumer implements RocketMQConsumer {
        // ...
    }
    

  • 核心线程数 < CPU核心数

  • 最大线程数

    • IO密集，读文件、操作数据库，CPU快，磁盘慢，CPU空闲很多，建议设置为2n，n是CPU的最大处理器数量，如下图所示，建议通过Runtime.getRuntime().availableProcessors()来获取，因为不同服务器这个是不一样的，不建议写死
      

    • CPU密集，CPU使用频繁，如果开太多，CPU核数不够用，会频繁切换，效率低，建议设置(n+1)

• 动态扩容队列数量（一般由运维工程师来决定），从而增加消费者数量。动态扩容之后，程序不是一下就感知到的，刚扩容的时候，新来的队列还是收不到消息，要过一段时间才会收到

  

  

  • 读队列数量不要设置大于写队列数量（读多没有用），直接设置相等就可以
  • perm：设置为2，这个主题的消息只能读不能写；设置为4，只能写，不能读；设置为6，可写可读
  • 当队列的最大位点不是全为0的话（如下图所示），不可以缩容，不然会出问题，有的队列的消息会丢失；全是0的时候，可以缩
    

消费者消费出现问题

• 排查消费者程序的问题

跳过堆积

跳过堆积，这个组的消息都不要了，偏移量会自动往后面移动，表示已经消费过。跳过之后，无法回滚，要谨慎

重置消费点位

从这个时间开始至今被消费过的消息，会重新被消费

如何确保消息不丢失？

硬盘读写方式：

• 随机读写：将数据不固定存储到不同的扇区，查询数据较慢
• 顺序读写：提前申请一片空间，将数据顺序存储（MQ使用的是这种）

方式一：将mq的刷盘机制设置为同步刷盘

消息持久化：

• 同步刷盘：生产者给broker发送消息，broker先把消息持久化到磁盘之后，再返回成功给生产者。安全，性能降低，但其实性能还是不错的
• 异步刷盘：先把数据存储到内存的buffer中，到达一定的量，再存储到磁盘中。不安全，性能好

方式二：生产者做日志

不用同步刷盘，生产者可以自己做消息日志，写到文件或者数据库中，不占用MQ的性能

• 生产者使用同步发送模式，收到mq的返回确认以后，顺便往自己的数据库里面写key createTime status=1。消费者消费以后，修改数据这条消息的状态 = 2，记录消息的handleTime
• 写一个定时任务，间隔两天去查询数据，如果有status = 1 and createTime < day-2，将这个消息补发一次

方式三：集群主备模式

单个硬盘存储，如果硬盘坏了，消息还是会丢失的，因此需要集群模主备模式，将消息持久化在不同的硬件上

方式四：开启mq的trace机制，消息跟踪机制

1、在broker.conf中开启消息追踪traceTopicEnable=true

2、重启broker

3、生产者配置文件开启消息轨迹enable-msg-trace: true

如果使用的是原生API，可以这样启动

4、消费者开启消息轨迹功能，可以给单独的某一个消费者开启enableMsgTrace = true

在rocketmq的面板中可以查看消息轨迹，默认会将消息轨迹的数据存在RMQ_SYS_TRACE_TOPIC主题里面