rocketMq、相关消息队列概念理解整理

rocketMq中的各部分概念组成
NameServer
NameServer也可以有多个
用来保存活跃的broker列表，包括Master和Slave
用来保存所有topic和该topic所有队列的列表
用来保存所有broker的Filter列表
记录维护Topic、Broker的信息，及监控Broker的运行状态
NameServer压⼒不会太⼤，平时主要开销是在维持⼼跳和提供Topic-Broker的关系数据
Broker向NameServer发⼼跳时， 会带上当前⾃⼰所负责的所有Topic信息
//自己：nameServer的存在原因之一是为了实现分布式？
Producer 在发送消息前会根据 Topic 到NameServer 获取到 Broker 的路由信息

Broken（消息代理？）
消息中转⻆⾊，负责存储消息，转发消息。
Broker可以有多个，但是每一个都要和所有的NameServer建立连接
每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server
每个 Broker 在启动的时候会到 NameServer 注册
Producer 在发送消息前会根据 Topic 到NameServer 获取到 Broker 的路由信息
broken分为master和slave
Broker在RocketMQ中是进⾏处理Producer发送消息请求，Consumer消费消息的请求，并且进⾏消息的持久化，以及HA策略和服务端过滤，就是集群中很重的⼯作都是交给了Broker进⾏处理。

Broken为什么要有多个，一个不行吗？
Broken为了可用性，也是需要集群的,所以要多个。
那么一个Master多个slave不就行了吗？为什么要有多个Master？
那么每个Broken的的数据一致吗？
目前理解：不一致。
每个Topic可以设置自己的Broken。
Topic可以分配在多个Broker上吗？
可以的，通常不设置Topic给某个指定的Broken，而是设置为某个集群。
故多个Broken中可以有相同的Topic。
消息进来时，Topic会有（默认8个队列，可以调整队列大小）分配到多个Broken中。
生产者生产的消息会尽量地分配到多个队列中。

Topic分配在多个Broke上，称为topic分片
在分布式数据库和分布式缓存领域，分片概念已经有了清晰的定义。
设计分片的好处：突破单点的资源（网络带宽，CPU，内存或文件存储）限制从而实现水平扩展。

为什么RocketMQ中Topic分片后还要分成多个queue
Queue是Topic在一个Broker上的分片等分为指定份数后的其中一份，是负载均衡过程中资源分配的基本单元。

RocketMQ的伸缩能力
具有很好动态伸缩能力(非顺序消息)，伸缩性体现在Topic和Broker两个维度
Topic维度：假如一个Topic的消息量特别大，但集群水位压力还是很低，就可以扩大该Topic的队列数，Topic的队列数跟发送、消费速度成正比。
Broker维度：如果集群水位很高了，需要扩容，直接加机器部署Broker就可以。Broker起来后向Namesrv注册，Producer、Consumer通过Namesrv 发现新Broker，立即跟该Broker直连，收发消息。

MessageQueue中的队列有几个？
是否可以设置？
Queue和topic有什么关系？

Producer
消息⽣产者，负责产⽣消息，⼀般由业务系统负责产⽣消息。
消息由Producer通过多种负载均衡模式发送到Broker集群。（Producer产生的消息先到broken？）

Producer发送消息后，如还未被消费者消费，那么消息放在哪里？为什么要Pro+消费后，网页中的界面才看得到数据？

消息领域模型
Topic
一条信息必须有一个主题
⼀个 Topic 可以有0个、1个、多个⽣产者向其发送消息
⼀个⽣产者也可以同时向不同的 Topic 发送消息
⼀个 Topic 也可以被 0个、1个、多个消费者订阅。
Tag
可以看作⼦主题，它是消息的第⼆级类型
Group
分组，⼀个组可以订阅多个Topic。
分为ProducerGroup，ConsumerGroup
Queue
在Kafka中叫Partition，每个Queue内部是有序的，在RocketMQ中分为读和写两种队列，⼀般来说读
写队列数量⼀致
Message Queue
Message Queue（消息队列），主题（Topic）被划分为⼀个或多个⼦主题，即消息队列。
⼀个 Topic 下可以设置多个消息队列，发送消息时执⾏该消息的 Topic
RocketMQ 会轮询该 Topic 下的所有队列将消息发出去。
⼀个Topic下可以有多个Queue
Offset
在RocketMQ 中，所有消息队列都是持久化，⻓度⽆限的数据结构
可以认为 Message Queue 是⼀个⻓度⽆限的数组，Offset 就是下标。

消息消费模式
集群消费
该模式下⼀个消费者集群共同消费⼀个主题的多个队列，⼀个队列只会被⼀个消费者消费
广播消费
消费者组中的每⼀个消费者进⾏消费

消息顺序
Orderly（顺序消费）
Concurrently（并⾏消费）

消息队列一般不能是单机的
消息队列中的消息，一般要对接多个系统，消息很重要，都是得集群/分布式的。提高可用性。

消息队列三个经典场景
异步、削峰、解耦

消息队列-异步
一句话：业务链路长时，可以把影响业务返回结果的操作做完直接返回，相关设计的操作保存在消息队列中，返回之后再进行其他业务。
例如：支付订单的时候，发短信的业务可以等待支付成功结果返回后才进行操作。

异步，可以开线程去做啊，为什么一定要用消息队列？
开线程去做：我理解，带来的直接结果就是代码写在一起了，那么将来增加新的流程，需要重新发布全部的东西。
用消息队列：只需要增加相应流程的该微服务就好了。接入系统简单。

消息队列-削峰
比如：一个方法需要对数据库进行写操作，数据库只能支持同时100个请求。（redis、服务器也有相应的承受能力。）
该应用有时候的峰值请求为500，不能全部打到数据库。那么，可以利用消息队列，保存待处理订单，之后再进行处理。（感觉和线程池的等待有些相通？）

使用消息队列的代价
维护中间件
重复消费
消息丢失
消息顺序
数据一致性—（关联：分布式事务，比如：下单、积分、短信都成功才算一次成功。）

消息队列的消费速度是怎么控制的？（RocketMq现成解决方案？）
用线程池在消费者内部控制
？估算后，应该是可以设置消费者一次性拿多少个队列中的元素的吧。

不要求顺序处理的时候，有必要使用消息队列吗？