1、MQ的好处：异步处理，应用解耦，高峰限流最常见

2、RocketMQ基本概念介绍：

        1）NameServer集群：注册中心，每个NameServer之间没有任何数据交互

        2）broker集群：

                    a）真主存储数据的地方，其中的topic，queue可以找到对应的文件夹。

                    b）同brokerName的broker节点归为一组，brokerId为从0开始逐个递增，其中brokerId为0的是master，其余的都为slave

                    c）每个broker节点，都与所有的NameServer保持长连接心跳(Netty实现)

                    d）CID：同ConsumerId，被认为属于同一消费者集群。消费模式：

                            i. 集群消费：同一个CID的不同服务，只会选一个服务消费该消息

                            ii.广播消费：该CID的所有服务，都会消费一次该消息

                    e）Topic和Tag和Queue和Key

                       Tag就视作Topic的子分类就行，性质上一模一样，在实际使用时比如Topic为商品分类，Tag为该类商品的品牌分类，再往下可以加一级Key

                       什么情况下收的到Topic(Tag)下，在所有Broker里的Queue?

                       什么情况下只收某一个Broker里的该Topic(Tag)下的Queue?

        3）producer集群：

                    a）与nameServer关系：单个producer节点只和单个nameServer节点保持长连接，如果该nameServer挂掉，producer节点会自动连接下一个nameServer节点直到找到可用的，无心跳。

                    b）与broker关系：单个producer节点和其连接的nameServer关联的所有broker保持长连接心跳

       4）consumer集群：

                    a）与nameServer关系：同producer与nameServer的关系

                    b）与broker关系：与对应的nameServer关联的所有broker都保持长连接心跳。consumer节点失去心跳后，会向所有消费者发通知，告诉他们“我死了，你们重新分配队列吧”

3、关联自己的开发项目：

      1）我们的ZMQ框架的好处：

                a）我们的可视化界面，可以将消息在不同环境间同步

                b）同一套如ZMQ框架，可以做到只替换底层引用的框架(如RocketMQ或者Kafka)，不需要动我们自己框架的代码。

                c）创建消费者，在我们ZMQ中等同于创建CID的过程。创建CID时，指定appCode，和哪个Topic下哪个Tag。使用时，只要@ZMQListener注解中，指定CID，就是指定了需要消费的消息了。勾选广播，就是广播模式，否则是集群模式

                4）创建生产者时，不指定Tag,默认对其下的所有Tag生效，在代码里发送消息时，才指定Tag。指定的appCode只是说这个生产者的逻辑是在哪个应用中发出，跟哪些应用能接没任何关系，是发往所有应用的

                5）生产者中的PID除了唯一标识一个生产者集群，有什么实质性作用吗？