你需要知道的RoketMQ

最新推荐文章于 2024-09-09 17:34:17 发布

tt8889

最新推荐文章于 2024-09-09 17:34:17 发布

阅读量225

点赞数

分类专栏： Java 文章标签：经验分享架构 java

本文链接：https://blog.csdn.net/tt8889/article/details/124456761

版权

本文深入探讨了RocketMQ的架构、核心概念和特性，包括Producer、Consumer、Broker、NameServer的角色，Topic、Queue、Tag的使用，以及读写队列不一致的影响。文章还讨论了RocketMQ的消费模型、网络模型和高可靠的分布式存储，强调了RocketMQ在多Topic场景下的高性能，并对比了与Kafka的存储设计。此外，还涵盖了RocketMQ的可用性策略和定时/延时消息功能。

摘要由CSDN通过智能技术生成

对于RocketMQ的架构图，在大体上来看和Kafka并没有太多的差别，但是在很多细节上是有很多差别的，接下来会一一进行讲述。

[](()3.2 RocketMQ名词解释

在3.1的架构中我们有多个Producer，多个主Broker，多个从Broker,每个Producer可以对应多个Topic,每个Consumer也可以消费多个Topic。

Broker信息会上报至NameServer,Consumer会从NameServer中拉取Broker和Topic的信息。

Producer：消息生产者，向Broker发送消息的客户端
Consumer：消息消费者，从Broker读取消息的客户端
Broker：消息中间的处理节点，这里和kafka不同，kafka的Broker没有主从的概念，都可以写入请求以及备份其他节点数据，RocketMQ只有主Broker节点才能写，一般也通过主节点读，当主节点有故障或者一些其他特殊情况才会使用从节点读，有点类似- 于mysql的主从架构。
Topic：消息主题，一级消息类型，生产者向其发送消息, 消费者读取其消息。
Group：分为ProducerGroup,ConsumerGroup,代表某一类的生产者和消费者，一般来说同一个服务可以作为Group,同一个Group一般来说发送和消费的消息都是一样的。
Tag：Kafka中没有这个概念，Tag是属于二级消息类型，一般来说业务有关联的可以使用同一个Tag,比如订单消息队列，使用Topic_Order,Tag可以分为Tag_食品订单,Tag_服装订单等等。
Queue: 在kafka中叫Partition,每个Queue内部是有序的，在RocketMQ中分为读和写两种队列，一般来说读写队列数量一致，如果不一致就会出现很多问题。
NameServer：Kafka中使用的是ZooKeeper保存Broker的地址信息，以及Broker的Leader的选举，在RocketMQ中并没有采用选举Broker的策略，所以采用了无状态的NameServer太存储，由于NameServer是无状态的，集群节点之间并不会通信，所以上传数据的时候都需要向所有节点进行发送。

很多朋友都在问什么是无状态呢？状态的有无实际上就是数据是否会做存储，有状态的话数据会被持久化，无状态的服务可以理解就是一个内存服务，NameServer本身也是一个内存服务，所有数据都存储在内存中，重启之后都会丢失。

[](()3.3 Topic和Queue

在RocketMQ中的每一条消息，都有一个Topic，用来区分不同的消息。一个主题一般会有多个消息的订阅者，当生产者发布消息到某个主题时，订阅了这个主题的消费者都可以接收到生产者写入的新消息。

在Topic中有分为了多个Queue，这其实是我们发送/读取消息通道的最小单位，我们发送消息都需要指定某个写入某个Queue，拉取消息的时候也需要指定拉取某个Queue，所以我们的顺序消息可以基于我们的Queue维度保持队列有序，如果想做到全局有序那么需要将Queue大小设置为1，这样所有的数据都会在Queue中有序。