RocketMQ学习(二）

昨天学习了基本的api使用，今天主要学习了如何使用springboot提供的rockmqTemplate对象发送不同类型的消息和消费，还了解到了消息的两种消费模式和消息堆积问题。最后了解了消费重试以及死信的知识，包括如何保证消息幂等性。

首先是如何解决消息的重复发送问题。消息重复发送会导致消费者多次消费同一条消息，如果是扣减库存的操作，就会扣减两次，这绝对是不允许的。

因此我们引入了解决方案:因为业务逻辑发生在消费者一端，所以我们更倾向于在消费者这边解决问题。我们知道 发送message的时候可以携带key，既可以是uuid 也可以是自己业务逻辑的key

当生产者把带有key的消息发送到topic里面后，假设生产者发送了两个相同key的消息（模拟故障），在消费端我们可以根据判断分支，只执行一次业务逻辑，下次来进来的时候直接returnSUCCESS

具体的代码示例如下：

 这里我们以插入一条数据为例，第二次插入的时候会报异常，所以我们在第二次直接返回success即可。

我们知道生产者和消费者都可以设置最大重试次数，对于同步消费者来说，如果不能成功消费消息，就会一直重试int最大值次数，

如果消息达到了最大的重试次数还没成功，这个消息会被放到一个名字叫%DLQ%[这里是消费者组的名字]   拼接起来的一个topic主题

我们可以使用一个消费者监听这个主题，然后把错误消息存储至文件或者数据库交给人工处理。

当然你可以不写单独的消费者，也可以采用如下的代码方式。

 当消息>=3时，也就是超过了最大重试次数，那么我们可以判断，直接把该消息处理完毕 然后返回SUCCESS 。

然后学习了在springboot中收发消息的方式。

 发送异步消息

 

发送顺序消息

 发送单向消息

 然后是消费者端的代码使用

 然后是消费者的两种模式 广播意味着每一个消费者都会消费一次 而下面的集群模式则对应负载均衡，消息会均衡分布在不同的消费者

 这里有一个注意的点，我先放一个图

这里如果有不同的消费者组均订阅了同一个Topic 那么这两个消费者组是独立互不干预的。队列里面的消息  每一个组都会执行一次。当然没有这么做的必要，如果想让不同的消费者组共享队列的数据，还不如放在一个消费者组里面呢。

最后还学习了消息堆积的问题。消息堆积是因为生产太快 消费太慢，不考虑消费者业务出现问题的前提下，我们可以增加队列的数量，也可以增加消费者的最大线程数量

以我本人的笔记本为例。我只有16个处理器 

 

 因此 如果我消费端是IO密集型的操作，我设置最大线程数为2 * n  如果消费端是CPU计算密集型操作，我设置线程数为 n + 1

 在这里我设置了最大线程数为逻辑处理器的二倍（因为是数据库操作 属于IO）默认是20个线程。

最后了解到主面板也有一些其他功能

 跳过堆积可以忽略一部分数据 

重置消费位点可以回溯消息，再次执行一次。