参考资料：

    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的定义，后续补充