这是我参与「第五届青训营」伴学笔记创作活动的第11天
简介 MQ（Message Queue）意为消息队列，通常指提供消息队列服务的中间件。 简单的说就是接收消息、存储消息、转发消息的东西。
MQ使用 MQ的应用场景很多，大致分为3类
流量削峰填谷 将系统过载的请求暂时存放在MQ中，然后在系统负载范围内慢慢消费。 一方面防止系统被过多的请求压垮，从而提高资源利用率。
业务异步解耦 一般情况下，服务A完成某些事情，然后发送一个通知，其他服务可以订阅这些消息来处理自己的逻辑。 一方面，A不关心订阅者的处理逻辑，不需要等待其他服务同步完成处理。 另一方面，增加或减少订阅者不需要改变A服务的代码。
海量数据采集 一般用在大数据行业，比如物联网行业，传感器无时无刻不在产生数据，一是数据量大，二是写入频率高。 传统数据库不适合直接处理此类数据。 而MQ非常适合作为这种数据存储的临时介质。 在这方面，卡夫卡主要独领风骚。
火箭MQ 为什么选择 RocketMQ？ MQ功能基本相同，市面上选择的不多。 我选择RocketMQ主要是因为以下几点：
高吞吐，天然支持集群部署 开发语言为Java，中文文档，简单易学 阿里巴巴出品，通过双11级别的高并发测试，消息支持零丢包配置。 主要概念 RocketMQ主要分为4个部分，Producer、Consumer、Name Server、Broker Server
制作人 即生产者负责发送消息。 主要是从NameServer中获取目标Broker的信息，然后向Broker发送消息。 消息支持同步发送、异步发送、顺序发送、单向发送
消费者 即消费者负责拉取和消费消息。 从消费者的角度来看，获取消息有两种方式：拉取消费（Pull）和推送消费（Push）。 同时提供了两种消费模式：集群消费和广播消费。
名称服务器 名字服务器，类似于微服务中的注册中心，保存着一些关于Brokers的信息，供生产者和消费者路由选择Brokers。
经纪人服务器 代理服务器负责存储和转发消息。 消息的元数据也存储在内部，包括消费组、消费进度、主题、队列消息等。
信息 实际消息的载体，包括实际消息和一些元数据，如Topic、Tag等。
话题 消息的集合，是RocketMQ订阅的基本单位
队列 topic内部进一步划分其实就是consumerqueue。 主题一般包含一个或多个队列，也区分了读和写的逻辑区别。 消息索引存储在队列中，实际消费的消息从这里取出。 集群模式 同时，一个队列只能被同一个消费者组中的一个消费者消费。
