参考资料：
https://blog.csdn.net/adaihao_/article/details/54296639
https://blog.csdn.net/qq924862077/article/details/84574455
一、名词解释
Name Server：作用类似于zookeeper之于kafka，主要做协调、心跳
Broker：接受和分发消息的核心组件，也是RocketMQ的核心
Message Model：消息消费方式，有两种
Clustering（集群消费）：MQ认为任意一条消息只要被集群中一个消费者消费掉即可
Broadcasting（广播消费）：MQ会推送给所有注册的消费者
消息细致类型：
普通消息：爱怎么发怎么发，爱怎么接怎么接，反正没有顺序
事务消息：经典的2PC提交
顺序消息：你怎么发，我怎么接，有顺序的消息
延迟消息：比如我们的订单，15分钟如果没有操作就会自动关闭订单，我觉得延迟消息可以做
Producer：生产者，产生消息的主体
Producer Group：
生产者组，主要作用是标识一类生产者，并且，在事务类型的消息中，当一个生产者宕机的时候，组内其他的生产者可以顶上去
Message:消息体
不得不说，看了阿里的源码，Message这个类一行注释也没有，心塞。
Message msg = new Message(topic,tags,keys,messagebody);
消息中主要有四个参数：
topic：主题
tags:按照阿里官方的解释，是第二主题，子主题
keys：消息关键词，据说是查找用的，后续学习到补充进来
messagebody：具体的消息内容
Consumer：消费者
Consumer Group：消费者组，这个阿里比较有良心给了一段警告：
Warning: consumer instances of a consumer group must have exactly the same topic subscription(s).
一个组内的消费者必须订阅同一个主题。 我的理解，不仅Topic要一致，tags也必须一致，下面举个例子说一下
这里有一个大坑，就是订阅一致性的问题，截止到目前，我的理解，可以试试下面这个例子：
参考链接：https://www.jianshu.com/p/524ef06ce25a
1、同一个组(Group1)内的两个消费者 (Consumer1、Consumer2)，同时订阅主题（Topic1）
2、Consumer1 订阅的tag为 A||B,Consumer2订阅的tag为 C
3、先启动Consumer1，然后启动Producer发送 topic=Topic1，tag=A的数据（假定10条），Consumer1正常接收
4、然后启动Consumer2，然后继续发送 topic=Topic1，tag=A的数据（假定10条），一条也收不到
5、继续发送 topic=Topic1，tag=C的数据（假定10条），Consumer2只接收到了一部分（我这里稳定6条），关闭所有Consumer，然后启动Consumer2，这时候剩下的4条可以被接收到，很显而易见，这些消息并没有reject
所以，以目前的知识水平，我认为，同一个Consumer Group中的消费者，不仅Topic必须一致，tags也必须一致，具体原因可以参考上面的链接，大致是因为RocketMQ会检索最后一个注册的Consumer的监听策略，之前的会失效。
Queue：队列，这个有区别于ActiveMQ及JMS的定义，后续补充