RocketMq架构高性能设计思路

本文主要介绍RocketMq在性能方面做的相关优化

RocketMq架构

经常会提到RocketMq，其性能多么多么好，那么各位有没想过，其性能为什么好？
先从RocketMq架构层面入手，先上一张架构图

RocketMQ 架构上由 Broker、NameServer、Producer 和 Consumer 组成，各个组件功能如下

• NameServer：注册中心和配置中心，管理集群的元数据，包括 Topic 信息和路由信息、Producer 和 Consumer 的客户端注册信息、Broker 的注册信息。是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
• Broker：消息存储端，负责接收消息的生产和消费请求，并进行消息的持久化和消息的读取。Broker 分为 Master 与 Slave，一个 Master 可以对应多个 Slave。每个 Broker 与 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server
• Producer：负责生产消息，Producer 与 Name Server 集群中的其中一个节点(随机选择)建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态，可集群部署
• Consumer：负责消费消息，Name Server 集群中的其中一个节点(随机选择)建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave 发送心跳。Consumer 既可以从 Master 订阅消息，也可以从 Slave 订阅消息，订阅规则由 Broker 配置决定

Producer端相关实现

Topic元数据缓存

先从生产者出发，生产者首先得把消息发送到Mq服务端(也就是Broker端)，自然得先知道这条消息得往哪个Broker上发(毕竟消息要做持久化，提供堆积能力，不然要Broker干嘛)，因此Producer需要从NameServer中获取Topic对应的路由元数据(元数据即指的是Topic对应的队列信息、Broker信息)，那么这个Topic的路由信息是不是可以缓存呢？

对应到代码里的实现如下org.apache.rocketmq.client.impl.producer.Defaul