📦 本次学习的是 RocketMQ4.x版本
🏢 官方文档: https://rocketmq.apache.org/zh/docs/
🏆 RocketMQ
MQ作用
1.可以做到削峰限流的作用，设置一个流程一个缓冲池，如果消息达到了最大值，就将消息放入缓冲池中
2.异步，在程序中同步和异步的概念为
同步: 一个动作完成以后才做下一个
异步: 两个动作同时进行
生产者将一个处理完的消息丢给消息队列之后并不需要阻塞等待消费者读取这条消息后才处理另外一个消息，丢完之后直接可以开始处理下一个消息
3.解耦合，剥离各个组件之间的关系
MQ的定义
MQ是面向消息的中间件(message-oriented middleware) MOM，是指利用高效可靠的消息传递机制进行与平台无关（跨平台）的数据交流，并基于数据通信来进行分布式系统的集成
通过提供消息传递和消息排队模型在分布式环境下提供应用解耦，弹性伸缩，冗余存储，流量削峰，异步通信，数据同步等
发送者把消息发给消息服务器[MQ]，消息服务器把消息存放在若干***
*队列*/*主题****中，在合适的时候，消息服务器会把消息转发给接受者。在这个过程中，发送和接受是异步的,也就是发送无需等待，发送者和接受者的生命周期也没有必然关系在发布pub/订阅sub模式下，也可以完成一对多的通信，可以让一个消息有多个接受者[微信订阅号就是这样的]
各个MQ对比
RocketMQ介绍
RocketMQ是阿里巴巴2016年MQ中间件，使用Java语言开发，RocketMQ 是一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。同时，广泛应用于多个领域，包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、移动应用、手游、视频、物联网、车联网等。
具有以下特点：
- 能够保证严格的消息顺序
- 提供丰富的消息拉取模式
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 亿级消息堆积能力
RocketMQ架构
下面是 RocketMQ官方文档的一个架构图
在基于主题的系统中，消息被发布到主题或命名通道上。消费者将收到其订阅主题上的所有消息，生产者负责定义订阅者所订阅的消息类别。这是一个基础的概念模型，而在实际的应用中，结构会更复杂。例如为了支持高并发和水平扩展，中间的消息主题需要进行分区，同一个 Topic会有多个生产者，同一个信息会有多个消费者，消费者之间要进行负载均衡等
消息发送的流程是，Producer询问 NameServer，NameServer分配一个 broker 然后 Consumer也要询问 NameServer，得到一个具体的 broker，然后消费消息
RocketMQ扩展后的消息模型
- 为了消息写入能力的水平扩展，RocketMQ 对 Topic进行了分区，这种操作被称为队列（MessageQueue）。
- 为了消费能力的水平扩展，ConsumerGroup的概念应运而生。
- 相同的
ConsumerGroup下的消费者主要有两种负载均衡模式，即广播模式，和集群模式（图中是最常用的集群模式）。- 在集群模式下，同一个
ConsumerGroup中的Consumer实例是负载均衡消费，如图中ConsumerGroupA订阅TopicA，TopicA对应 3个队列，则GroupA中的Consumer1消费的是MessageQueue0和MessageQueue1的消息，Consumer2是消费的是MessageQueue2的消息,也就是每个消费者指定消费一个topic中的某一个/多个队列，如果topic中只有3个队列，消费者组内有4个消费者，那么会有一个消费者永远没有消息。- 在广播模式下，同一个
ConsumerGroup中的每个Consumer实例都处理全部的队列。需要注意的是，广播模式下因为每个Consumer实例都需要处理全部的消息，因此这种模式仅推荐在通知推送、配置同步类小流量场景使用。
RocketMQ部署模型的图
Producer：消息的发送者，生产者；负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。举例：发件人
Consumer：消息接收者，消费者；负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。举例：收件人
- 支持以推（
push），拉（pull）两种模式对消息进行消费。 - 同时也支持集群方式和广播方式的消费。
- 提供实时消息订阅机制，可以满足大多数用户的需求。
Broker：暂存和传输消息的通道；举例：快递
在
Master-Slave架构中，Broker分为Master与Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个
Broker角色分为ASYNC_MASTER（异步主机）、SYNC_MASTER（同步主机）以及SLAVE（从机）。如果对消息的可靠性要求比较严格，可以采用SYNC_MASTER加SLAVE的部署方式。如果对消息可靠性要求不高，可以采用ASYNC_MASTER加SLAVE的部署方式。如果只是测试方便，则可以选择仅ASYNC_MASTER或仅SYNC_MASTER的部署方式。
NameServer：管理Broker和路由信息；举例：各个快递公司的管理机构 相当于broker的注册中心，保留了 broker的信息；NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台 NameServer注册自己的路由信息，所以每一个 NameServer实例上面都保存一份完整的路由信息。当某个 NameServer因某种原因下线了，客户端仍然可以向其它 NameServer获取路由信息
Queue：队列，消息存放的位置，一个Broker中可以有多个队列
Topic：主题，消息的分类；表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是 RocketMQ进行消息订阅的基本单位
ProducerGroup：生产者组
ConsumerGroup：消费者组，多个消费者组可以同时消费一个主题的消息
RocketMQ集群工作流程
- 启动NameServer
启动NameServer。NameServer启动后监听端口，等待Broker、Producer、Consumer连接，相当于一个路由控制中心。
- 启动 Broker
启动 Broker。与所有 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息以及存储所有 Topic 信息。注册成功后，NameServer 集群中就有 Topic跟Broker 的映射关系。
- 创建 Topic
创建 Topic 时需要指定该 Topic 要存储在哪些 Broker 上，也可以在发送消息时自动创建Topic。
- 生产者发送消息
生产者发送消息。启动时先跟 NameServer 集群中的其中一台建立长连接，并从 NameServer 中获取当前发送的 Topic存在于哪些 Broker 上，轮询从队列列表中选择一个队列，然后与队列所在的 Broker建立长连接从而向 Broker发消息。
- 消费者接受消息
消费者接受消息。跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，然后开始消费消息。
