RocketMq | 整体架构

4.x 架构

5.x 架构

Nameserver / Broker / Proxy

nameserver 是 rocketMq 的注册中心，其作用完全相当于 zookeeper 之余 kafka
其他角色包括 broker、proxy、producer、consumer 都会将自己的元数据注册上去

broker 是 rocket 的数据中心，消息、索引等都保存在 broker 上

proxy 其实是 broker 的代理，可以直接理解成 broker 的统一接口层，对于 broker 的访问统一由 proxy 转发
包括发送、拉取消息，获取路由数据，以及命令行访问

为什么 rocketMq 要开发一个 nameserver

持有一个自己的 nameserver 作为注册中心，可以避免依赖三方组件，做到解耦与内聚
并且，nameserver 的设计足够简单，可以节省不必要的系统资源

为什么会有 proxy

从 4.x 的架构看，broker 是整个架构的核心

• nameserver 需要持有 broker 的元数据，然后才能给 consumer、producer 提供路由能力
• producer 需要直连 broker 的主节点发送消息
• consumer 需要直连 broker 的所有节点（优先主）消费消息
• broker 负责数据的存储
  但从职责划分上来说，broker 的核心工作有且只有存储数据

另一方面，client 无论是发送还是消费消息时，都需要由自己决定

• 协议
• 权限校验
• 连接哪个 broker
• 拼装消息

但从职责划分上来说，client 的核心工作只应该是：发送请求然后收到响应
同时，client 还涉及跨语言问题，client 需要给不同的语言提供 sdk 能力
因为上面的琐事存在，势必导致对应的开发量增加

综上 rocketMq 加入了 proxy

• 从 broker 中剥离了计算
• 从 client 中剥离了决定协议、权限、路由等职责

5.x 引入 proxy 后，给 rocketMq 带来了什么变化

• producer、consumer 不需要将自己注册到 nameserver，只与 proxy 通讯即可
  • 之前需要注册是为了接受 nameserver 的注册信息，并以此为基础直连 broker
  • 但现在注册信息 proxy 上就有，对 broker 的实际访问也是 proxy 转发的，因此也就完全没有必要了
• producer、consumer 不再直连 borker，只与 proxy 通讯即可
• 与 broker 的实际通讯转为了服务端内部的通讯，client 更加轻量级，扩展性增强
• 与 broker 的实际通讯均由 proxy 转发，broker 不再承担存储之外的职责

5.x 引入 proxy 后，对业务上会有什么影响

会增加延时，毕竟多了一级网络访问
如果想避免这个问题，可以使用 rocketMq 提供的 local 部署模式
local 模式下，proxy 与 broker 会部署在同一个机器上，因此，网络访问变成进程内访问，进而减少延时