说起来这也是个挺悲伤的故事，之前项目中用过ribbitMQ，然后新公司用的rocketMQ，虽然确实两者其实在被spring boot封装以后使用起来大同小异，但是还是遇到了点小问题，所以这里简单整理下。
首先引入jar包
我上面都说了用的是spring boot框架，所以引入的rocketMQ的jar包也是spring的场景启动器：
<!--mq-->
<dependency>
<groupId>org.apache.rocketmq</groupId>
<artifactId>rocketmq-spring-boot-starter</artifactId>
<version>2.0.4</version>
</dependency>
RocketMQ的配置
其实这里我遇到了个大坑。因为一开始我不太熟悉这个用法，下意识的就像用万能的模板。也就是RocketMQTemplate。然后就报错了。说没有这个bean。然后开始翻源码。发现了个小秘密：这个看似spring boot整合的rocket其实是自己凑上来的。类似于mybatis。jar包的命名都是rocketmq在前面。当然了这是小问题，继续去翻源码，关于RocketMQTemplate的写法：
然后这个类其实比较好理解，大概的层级关系如下：
简单分析一下，这里用了大量的条件注解。
- 首先要有rocketmq的name-server这个配置类才会生效。
- 第一个判断会不会生效的bean是DefaultMQProducer。这个注解的小件也比较简单：首先没有这个bean，其次是配置文件中要有"name-server", "producer.group"这两个属性。
- 第二个bean就是我们想要的RocketMQTemplate。这个类的条件注解也是两个：一个是不存这个bean，第二个很重要，是要存在DefaultMQProducer，也就是我们第一步获得的bean。
后面的就不一一分析了，简单来讲，这里RocketMQTemplate不存在只能是DefaultMQProducer不存在。而这个不存在的唯一原因："name-server", "producer.group"这两个参数有缺。
自我感觉找到问题了，然后屁颠屁颠去看了配置文件。哎呦，真的没有producer.group属性。
就在我抱着发现新大陆的心态想要高喊一声我找到项目的bug的时候，转头一想不太对啊，我们项目中的配置是走的配置中心，别的项目组用rocket.yml都没问题，理论上配置文件不应该有错啊。
于是乎迂回问了我们组长：我们的组名是什么啊？然后组长回答我了以后我又佯装无意的提了下：这个不用写在配置文件里么？
然后组长告诉我：因为我们项目中有多个推送，有不同组别。所以这里组别写在代码里的。
我乖乖点了点头，然后滚去敲代码了。
仔细分析了下，其实把组别写在代码里的意思应该是自己去写这个rocketMQTemplate而不用注入bean。但是真要是不拿现成的，也没必要非执着于rocketMQTemplate了，可以直接用DefaultMQProducer。果然点进原码发现这个类提供了传组别作为参数的构造方法：
于是乎代码就很顺利的写出来了：
RocketMQ消息接收
这个就没啥好说的了，也比较简单。
用默认的DefaultMQPushConsumer就可以。就不多说了。
本篇笔记就到这里，如果稍微帮到你了记得点个喜欢点个关注。也祝大家工作顺顺利利，身体健健康康！其实这个问题挺小的，但是第一次把看源码用在了工作中，觉得比较值得纪念，嘿嘿~
