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架构是怎么样的”这篇文章的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注行业资讯频道!