RocketMQ架构是怎么样的

这篇文章主要介绍RocketMQ架构是怎么样的，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

一、总体架构

RocketMQ是开源的一个分布式消息中间件。在RocketMQ中包含四个主要角色：nameserver，元数据管理服务；broker，接收、存储、分发消息；producer，消息生产者；consumer，消息消费者。整体架构如下图

Nameserver是一个无状态的服务，各个nameserver之间无数据交互。每个borker都会向所有nameserver保持心跳消息，将broker上的topic存储信息上报到nameserver。producer/consumer会随机选择一个nameserver建立长链接，从nameserver定时拉取订阅的topic的路由信息。

Broker是消息存储服务器，一个broker可以包含一个master以及多个slave，master和slave之间形成主备关系。master之间无任何通讯，也就是说rocketmq不会在master之间自动重新分配topic的存储。一个topic可以存储在多个broker上，每个broker上又可以分成多个queue，以降低读写的压力。topic的存储如下图所示，其中topic和broker之间的对应关系是需要管理员人为指定的。producer和consumer会和订阅的topic所在的broker建立长链接，用于拉取和消费消息。

Producer是消息生产者，多个发送同种消息的producer可以归到同一个producer group。

Consumer是消息消费者，rocketmq存在两种消息消费方式：广播，同一个消息会发送给所有消费者；集群，同一个消息只会发送给一个消费者。同一个类型的消费者可以组成一个consumer group.

二、消息模型

Message代表一个消息，一个message有两个标识的id：msgid & offsetMsgId：

• msgId是producer生成的，全局唯一，也叫做uniqId。存储在Message.properties里，存储的key是“UNIQ_KEY”。

• offsetMsgId，是由存储的broker的服务器地址以及commitlog的offet两者拼接而成的。存储在MessageExt.msgId中。

除了msgid & offsetMsgId之外，消息还可以指定一组keys。broker会把message的keys解析，存储到一个索引服务（IndexService）当中，支持按key来搜索消息。

RocketMQ的message还支持tag，可以在发送消息时指定tag，并按tag进行订阅。broker会把消息的tag计算成一个hashcode，存储到ConsumeQueue当中，这样在订阅时就可以快速过滤出包含特定tag的消息。

为了支持消息的快速写入、读取、按key搜索、按tag订阅，rocketmq的消息存储采用如下架构：

• commitlog用来存储消息原文，不分topic，按顺序append到末尾。对于每个消息有一个对应的offset，代表在commitlog中的偏移量。

• ConsumeQueue按topic存储，每个element是固定的20字节的长度，包含一个消息的offset + size + taghashcode。

• IndexFile存储消息的key索引，同一个broker上的所有topic共享同一个index服务。indexservice当中会以“topic#key”的形式来存储消息基于key的反向索引。

以上是“RocketMQ架构是怎么样的”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注亿速云行业资讯频道！