简述RcoketMQ
概念：RocketMQ是一个开源的分布式消息中间件，由阿里巴巴开发并贡献给Apache软件基金会。它用于处理高吞吐量、低延迟的消息传递，并广泛应用于现代分布式系统中。
1 基本概念
1.1 消息 (Message)
概念：消息是信息传递的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。
模型图：
1.2 主题 (Topic)
概念：
1.主题是消息的分类标识，用于区分不同类型的消息。
2.每条消息只能属于一个主题，一个生产者可以同时发送多种主题的消息，而一个消费者只对某种特定的主题感兴趣，即只可以订阅和消费一种主题的消息。
模型图：
1.3 标签 (Tag)
概念：为消息设置的标签。通过使用标签，消费者可以选择只接收特定类型的消息。
标签通常用于在同一主题内区分消息的不同子类型或处理方式。消费者可以根据标签是实现对不同子主题的不同消费逻辑，实现更好的扩展性。
1.4 队列 (Queue)
概念：队列是存储消息的物理结构，通常与主题相关联。每个主题可以对应多个队列，消息在队列中有序存储。
补充:消费者从队列中拉取消息进行处理。队列的使用有助于实现负载均衡和消息的顺序消费。多个分区可以有多个消费者，一个分区只能有一个消费者。
1.5 消息标识 (Messageid/Key)
概念：RocketMQ中每个消息拥有唯一的MessageId, 且可以携带具有业务标识的Key,以方便对消息的查询。
注意:MessageId有两个:在生产者send(消息时会自动生成一个MessageId (msgId)， 当消息到达Broker后，Broker也会自动生成一 个Messageld(offsetMsgId)。 msgId、 offsetMsgId与key都称为消息。
补充：
1.msgId: 由producer端生成， 其生成规则为:
producerIp +进程pid + MessageClientIDSetter类的ClassLoader的hashcode +当前时间+ Automi CInteger自增计数器
2.offsetMsgId: 由broker端生成， 其生成规则为: brokerIp +物理分区的offset
3.key:由用户指定的业务相关的唯一标识
2 系统架构
模型图：
2.1 生产者（Producer）
消息生产者，负责生产消息。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败且低延迟。
模型图：
在RocketMQ中消息生产者都是以生产者组的形式出现的。生产者组都是同一类生产者的集合，这类Producer发送相同主题类型的消息。
2.2 消费者和消费者组（Consumer和ConsumerGroup）
消息消费者，负责消费消息，一个消息消费者会从Broker服务器中取得消息，并对消息进行相关业务处理。
同理，在RocketMQ中消息消费者都是以消费者组的形式出现，消费者组是同一类消费者的集合，这类Consumer消费的是同一个主题类型的消息。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。
消费者组中Consumer的数量应该小于等于订阅Topic的Queue的数量，如果超出Queue数量，则多出的Consumer将不能消费消息。
一个Topic类型的消息可以被多个Consumer Group同时消费。
注意：
1.消费者组只能消费一个Topic的消息，不能同时消费多个Topic消息。
2.一个消费者组中的消费者必须订阅完全相同的Topic
2.3 消费点位（offset）
由于不同消费者组之间的消息消费互不影响，当一个消费者组读取消息后，无法立即将其从MQ中移除。若移除，其他消费者组将无法读取；若不移除，则无法确定当前消费者组的消费进度。
因此，通过Offset来标识一个消费者组的当前消费位置，每成功消费一条记录：Offset + 1。(MQ ≈ 数组，Offset ≈ 数组下标)
2.4 Name Server
概念：其为一个Broker和Topic路由的注册中心，支持Broker动态注册和发现。
2.4.1 路由注册
NameServer以集群方式部署，集群中的各个节点间无差异，互相不通讯。数据同步依靠Broker节点与每一个NameServer节点进行长连接，发起注册请求。（Broker节点为证明自己存活，会将最新信息以心跳包的方式上报NameServer，每30s一次。）
优缺点：1.NameServer集群搭建简单。2.对于Broker要明确指出所有NameServer的地址，否则未指出地址的不会注册，故NameServer不可随意扩容，因为不重新配置Broker，新增的NameServer对于Broker不可见。
2.4.2 路由剔除
由于Broker关机、宕机或网络抖动，NameServer没有收到Broker的心跳，则NameServer会将其从Broker列表中删除。NameServer中的定时任务会每隔10s扫描一次Broker列表并查看其最新心跳时间戳，距离当前时间超过120s,则判定Broker失效，将其从Broker列表中剔除。
2.4.3 路由发现
RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时，NameServer不会主动推动给客户端，而是由客户端定时拉取主题最新的路由，默认每30s拉取一次，所以存在实时性较差的问题。
补充：1.Push模型：推送，实时性较好，需要维护一个长连接。2.Long Polling模型：长轮询模型，为Push和Pull模型的整合。
2.4.4 客户端（Producer和Consumer）NameServer选择策略
首先采用随机策略进行选择，失败后采用的是轮询策略。
2.5 Broker
概念：消息中转角色，负责存储消息、转发消息。在RocketMQ系统中负责接收并存储生产者发送来的消息，同时为消费者的拉取请求做准备。同时也存储消息的元数据。
2.5.1 模块构成
解释：
Remoting Module：整个Broker的实体，负责处理client端的请求。
Client Manager：客户端管理器，负责接收、解析客户端的请求，管理客户端。
Store Service：存储服务，提供方便简单的API接口，处理消息存储到物理硬盘和消息查询功能
HA Service：高可用服务，Master和Slave间的数据同步。
Index Service：索引服务，根据特定的Message Key，对投递到Broker的消息进行索引，也提供快速查询功能。
2.5.2 详解
Broker以集群形式出现。各集群中可能存放相同Topic的不用Queue。
可能出现问题以及解决方法：如果某个Broker宕机，为了数据不丢失，会将每个Broker集群节点进行横向扩展，将Broker节点在建一个HA集群，解决单点问题。
Broker是一个主从集群，集群中有Master和Slave。Master：负责读写操作。Slave：Master中国的数据的备份，Master挂了，Slave自动切换为Master。一个Master有多个Slave，一个Slave有一个Master。通过指定相同的BrokerName、不同的Brokerid来确定Master和Slave的对应关系，0为Master,非0为Slave。
