你知道RocketMQ消息队列吗？_rocketmq默认队列

一、概念

        MQ全称为Message Queue，即消息队列，是一种提供消息队列服务的中间件，也称为消息中间件，是一套提供了消息生产、存储、消费全过程的软件系统，遵循FIFO原则。

二、使用场景

1、限流削锋

2、异步解耦

3、数据收集

4、大数据处理

三、原理

        RocketMQ 是一个分布式的消息中间件系统，主要由三个重要部分组成：NameServer，Broker 和 Producer/Consumer。

• NameServer：

NameServer 是 RocketMQ 集群的管理和协调中心。它主要负责维护注册的 broker 地址和 topic 信息，相当于一个路由器。每个 RocketMQ 集群可以有多个 NameServer，客户端通过 NameServer 获取 Broker 的路由信息，并向 Broker 发送消息。

• Broker：

Broker 是 RocketMQ 的核心组件，消息队列的存储和管理都是由 Broker 负责。Broker 实现了 Message Store 存储消息，同时也具备消息检索和消息推送的功能。

• Producer：

Producer 负责将消息发送到 Broker，每个 Producer 可以发送消息到多个 Topic。在发送消息时，Producer 首先从 NameServer 上获取到 Broker 的地址信息，并向 Broker 发送消息。

• Consumer：

        Consumer 是消息消费者，它订阅 Topic 并从 Broker 上拉取消息。当 Broker 有新消息时，它会将消息推到订阅该 Topic 的所有 Consumer，一旦消息被确认，Broker 就会将其从消息队列中删除。

        RocketMQ 的消息传递是基于主题（Topic）和标签（Tag）的。每个消息都属于特定的主题，并且可以为消息设置标签信息。消费者通过订阅特定主题及标签的方式来消费消息。

        其实质是基于一种发布/订阅模型（Publisher/Subscribers）。如果没有消息的消费者，Broker 就会把消息缓存在 Topic 的 Message Queue 中，消费者存在后会从队列中取数据进行消费。

        在 RocketMQ 中，Producer 和 Consumer 之间的消息传递是基于“发布/订阅”模式的。Producer 将消息发送到 Broker，Consumer 订阅感兴趣的 Topic 以及 Topic 下面的一到多个 Tag。每个消息都被标识了 Topic 和 Tag 信息，让 Consumer 根据感兴趣的 Topic 和 Tag 来订阅消息。

        Tag 是 RocketMQ 提供的一种过滤消息的机制。通过在生产者端为消息设置 Tag，消费者就可以只消费自己感兴趣的 Tag 类型的消息，而忽略掉其他的消息。Tag 可以认为是对一组消息的二级分类，它将一个 Topic 下面的消息进行进一步的分类。通过标签，一个应用程序可以只消费它感兴趣的消息类型。

        Consumer 比 Producer 多一个 Tag 参数，是为了避免一些意外情况。首先，在实际应用场景中，我们可能需要在同一个 Topic 下发布不同类型的消息，这个时候就可以用 Tag 进行区分。其次，如果 Consumer 未指定 Tag，那么该 Consumer 将会消费该 Topic 下所有的消息，这可能会带来副作用和性能问题。因此，建议 Consumer 在消费消息时一定要指定具体的 Tag，以获得更精确的消息消费效果和更好的消费性能。

        广播模式下生产者发送的消息会被发送到所有订阅了该主题的消费者中，每个消费者都能独立地获取相同的消息，因此同一条消息可以被多个消费者消费；而集群模式中，多个消费者接受同一队列的消息，但是同一条消息只会被其中一个消费者处理，其他的消费者不会再消费这条消息，因此同一条消息只能被一个消费者消费。

消息拉取模式：

        在消息队列的消费模型中，push模式和pull模式各有优缺点。相比于pul模式，push模式可以更加及时地将消息推送给消费者，不需要消费者主动拉取，实时性更好。而pul模式则可以更加精细地控制消息消费的速率和流量，对于复杂的消费场景和负载均衡更为合适。之所以现在不推荐使用pull方式的原因是: pul模式需要消费者主动拉取消息，这就需要消费者保持长时间的连接，并在一定的频率下主动进行消息拉取，既会增加客户端的负担，也会对服务端产生较大的压力。同时，拉取的频率也会受到网络环境、服务端负载等因素的影响，会导致消费延迟和消息不均衡等问题。在RocketMQ官方文档也强烈建议尽量使用push模式方式进行消息消费。RocketMQ提供的推荐架构方案也为push模式进行了优化，包括了消息流量控制、push消费者的负载均衡等功能，以确保消息的及时性、稳定性和可靠性。虽然pul模式可能仍然适用于某些特殊场景，例如需要实现精细的消息流量控制、处理特定类型的消息等，但综合来看，推荐使用push模式进行消息消费。

消息消费模式：

1、广播：在不同的消费者组下只能被一个consumer消费

2、集群：只能被一个consumer消费，不管什么情况下，保证消息不会被重复消费

MessageQueue：

1、一个Queue在一个消费者组中只能有一个消费者，可以被多个消费者组消费。一个消费者可以有多个Queue。

2、consumer的数量要小于等于Queue的数量，这是为了保证consumer的资源不会空闲浪费

3、一个消费者组最好只订阅一个topic，不要订阅不同的topic

4、如果消费者组下的某个消费者挂了，那么要重新分配Queue与consumer的关系

topic的创建时机

开发环境：我们可以在启动Broker的时候指定autoCreateTopicEnable=true，那么生产者在启动时就会去自动帮我们创建此topic；在第一次发送消息的时候，生产者发送消息到Broker，Broker发现没有此topic，会去检测是否开启enable=true，如果没有开启报错找不到此topic，如果已开启，那么会告诉生产者要创建topic，他会根据TBW102这个MQ默认启动就有的topic拷贝一份变为你要创建的topic，往这里面发送消息。

生产环境：生产环境严禁使用自动创建，生成环境要提前在可视化界面先创建好再启动项目。自动创建是连到哪个Broker就在那个Broker中创建topic，其他集群Broker下没有，这会导致集群失效，所以生成环境不允许使用。

Queue分配算法

1、轮询：平均分配

2、环形平均：在环上面有序一人一次

3、一致性Hash策略：致性Hash策略: 该算法将Consumer的Hash值作为节点放到Hash环上，然后将Queue的hash值也放入Hash环上，通过顺时针进行就近分配。

4、同机房策略: 该算法会根据aueue的部署机房位置和consumer的位置，过滤出当前consumer相同机房的queue。然后按照平均分配策略或环形平均策略对同机房queue进行分配。如果没有同机房queue，则按照平均分配策略或环形平均策略对所有queue进行分配。

四、消息种类

4.1、单向消息：不响应任何结果，发送消息发了就发了没有结果通知。

4.2、同步消息：发送消息的那一句代码一定要等到MQ返回发送消息的结果。

4.3、异步消息：发送消息的那一句代码的执行结果跟后面的代码的执行是异步的，消息的发送结果也是在回调中获取，类似于Axios异步请求。

4.4、延迟消息：可以用作定时器

简要流程：生产者发送消息，消息进入到MQ的延迟队列，MQ还会准备一个监听器去监听消息到时间没有，如果到了就把消息重新投递到对应的topic中进行消费，RocketMQ默认给我们准备了18个延迟等级。

4.5、事务消息：是为了保证分布式事务所提供的消息。