RocketMQ(一)架构原理

lvtao

发布于：2020年9月1日

简介

RocketMQ是阿里巴巴开源的消息中间件，使用Java语言开发，具有高吞吐量、高可用性，适合大规模分布式系统应用的特点。设计方面参考了kafka的整体机制和架构设计，并在此基础上添加了分布式事务、定时消息、消费失败重试、回溯消息等功能，虽然在吞吐量上无法企及kafka，但是扩展的诸多功能相对于kafka来说，更能胜任电商、金融等领域的复杂业务场景。

核心组件

Broker:
Broker是集群中最核心的，也是最复杂的组件，负责消息的存储、投递、查询，以及保证服务的高可用，支持容错机制、灾备机制、报警机制和丰富的监控指标。

NameServer:
NameServer可以看作是RocketMQ的注册中心，类似于Dubbo、kafka的注册中心zookeeper，broker启动后会将自身管理的topic-queue信息注册到NameServer，为Producer或Consumer提供路由。

Name Server集群实例之间不会互相通讯，但是Broker会向所有的Name注册路由信息，所以每个NameServer实例上都保存了完整的路由信息。

Producer:
Producer是发布消息的角色，在程序启动后通过NameServer获取所有Broker的路由信息，通过多种负载均衡的方式，选择相应的Broker Server 集群中的Queue发送消息。Producer 在发送消息时，支持快速失败，并且是低延迟的。

Consumer:
Consumer是消费消息的角色，支持PUSH和PULL两种获取消息模式，支持集群和广播两种消费消息模式。

消息领域模型

Topic:
Topic的作用是将整个RocketMQ集群的消息进行划分，使不同类型的消息区分开来，以便于消费者针对不同的消息类型做不同的业务处理。

Tag:
Tag可以看作是消息的二级分类，一般在相同业务模块中通过引入标签来标记不同用途的消息，另外RocketMQ允许消费者按照Tag对消息进行过滤，也可以通过Tag过滤不需要的数据。

Message:
Message就是我们发送或消费的消息，用户在发送消息的时候可以设置messageKey，也就是消息的唯一识别MessageId，便于后续的查询和追踪。

Producer Group:
开发者在启动Producer时可以指定一个生产组，如果没有指定会自动生成一个(默认为DEFAULT_PRODUCER)。Producer Group主要用于推送事务消息，比如Producer在投递事务消息时宕机，本地事务回滚，可以继续联系该组下的另外一个生产者实例，不至于导致业务走不下去。

Consumer Group:
开发者在启动Producer时可以指定一个消费组，用于负载均衡共同消费消息。

部署模型

Broker特点:
Broker服务分为Master与Slave，一个Master可以对应多个Slaver，Master与Slaver的对应关系通过指定相同的BrokerName、不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slaver。

Producer特点:
Producer服务会随机与NameServer集群中的一个节点建立长连接，定期从NameServer获取topic-queue路由信息，然后与topic-queue所在的 BrokerServer的Master节点建立长连接，并且会定时向Master发送心跳。Producer集群完全是无状态的，可以随意集群部署。

Consumer特点:
Consumer服务会随机与NameServer集群中的一个节点建立长连接，定期从NameServer获取topic-queue路由信息，然后与topic-queue所在的BrokerServer的Master节点建立长连接，并且会定时向Master和Salve发送心跳。

Consumer既可以从Master订阅消息，也可以从Salve订阅消息，Consumer在获取消息的时候，BrokerServer的Master节点会根据获取消息的偏移量与最大偏移量的距离、服务器是否可读等因素建议Consumer下次是从 Master或者Salve获取消息。

topic分布

集群中所有topic都是以queue(1个或多个)的形式分散存储在各broker节点中，其中每个queue仅仅保存topic的一部分消息数据。这种架构设计与redis、elasticsearch的分片模式很相似，可以在整个RocketMQ集群服务运行过程中动态改变queue的数量，来控制同一时刻topic的并行处理能力。

假设一个Broker集群有3个节点，并且整个集群存储了3个topic: