FantasticMao 技术笔记
BlogGitHub
  • README
  • C & Unix
    • C
      • 《C 程序设计语言》笔记
      • C 语言中的陷阱
      • CMake 示例
      • GNU make
      • LLVM Clang
      • Nginx 常用模块
      • Vim 常用命令
    • Unix-like
      • 《深入理解计算机系统》笔记
      • 《UNIX 环境高级编程》笔记 - UNIX 基础知识
      • 《UNIX 环境高级编程》笔记 - 文件 IO
      • 《UNIX 环境高级编程》笔记 - 标准 IO 库
      • 《鳥哥的 Linux 私房菜》笔记 - 目录配置
      • 《鳥哥的 Linux 私房菜》笔记 - 认识与学习 bash
      • 《鳥哥的 Linux 私房菜》笔记 - 任务管理
      • OpenWrt 中的陷阱
      • iptables 工作机制
  • Go
    • 《A Tour of Go》笔记
    • Go vs C vsJava
    • Go 常用命令
    • Go 语言中的陷阱
  • Java
    • JDK
      • 《Java 并发编程实战》笔记 - 线程池的使用
      • 设计模式概览
      • 集合概览
      • HashMap 内部算法
      • ThreadLocal 工作机制
      • Java Agent
    • JVM
      • 《深入理解 Java 虚拟机》笔记 - Java 内存模型与线程
      • JVM 运行时数据区
      • 类加载机制
      • 垃圾回收算法
      • 引用类型
      • 垃圾收集算法
      • 垃圾收集器
    • Spring
      • Spring IoC 容器扩展点
      • Spring Transaction 声明式事务管理
      • Spring Web MVC DispatcherServlet 工作机制
      • Spring Security Servlet 实现原理
    • 其它
      • 《Netty - One Framework to rule them all》演讲笔记
      • Hystrix 设计与实现
  • JavaScript
    • 《写给大家看的设计书》笔记 - 设计原则
    • 《JavaScript 权威指南》笔记 - jQuery 类库
  • 数据库
    • ElasticSearch
      • ElasticSearch 概览
    • HBase
      • HBase 数据模型
    • Prometheus
      • Prometheus 概览
      • Prometheus 数据模型和指标类型
      • Prometheus 查询语法
      • Prometheus 存储原理
      • Prometheus vs InfluxDB
    • Redis
      • 《Redis 设计与实现》笔记 - 简单动态字符串
      • 《Redis 设计与实现》笔记 - 链表
      • 《Redis 设计与实现》笔记 - 字典
      • 《Redis 设计与实现》笔记 - 跳跃表
      • 《Redis 设计与实现》笔记 - 整数集合
      • 《Redis 设计与实现》笔记 - 压缩列表
      • 《Redis 设计与实现》笔记 - 对象
      • Redis 内存回收策略
      • Redis 实现分布式锁
      • Redis 持久化机制
      • Redis 数据分片方案
      • 使用缓存的常见问题
    • MySQL
      • 《高性能 MySQL》笔记 - Schema 与数据类型优化
      • 《高性能 MySQL》笔记 - 创建高性能的索引
      • 《MySQL Reference Manual》笔记 - InnoDB 和 ACID 模型
      • 《MySQL Reference Manual》笔记 - InnoDB 多版本
      • 《MySQL Reference Manual》笔记 - InnoDB 锁
      • 《MySQL Reference Manual》笔记 - InnoDB 事务模型
      • B-Tree 简述
      • 理解查询执行计划
  • 中间件
    • gRPC
      • gRPC 负载均衡
    • ZooKeeper
      • ZooKeeper 数据模型
    • 消息队列
      • 消息积压解决策略
      • RocketMQ 架构设计
      • RocketMQ 功能特性
      • RocketMQ 消息存储
  • 分布式系统
    • 《凤凰架构》笔记
    • 系统设计思路
    • 系统优化思路
    • 分布式事务协议:二阶段提交和三阶段提交
    • 分布式系统的技术栈
    • 分布式系统的弹性设计
    • 单点登录解决方案
    • 容错,高可用和灾备
  • 数据结构和算法
    • 一致性哈希
    • 布隆过滤器
    • 散列表
  • 网络协议
    • 诊断工具
    • TCP 协议
      • TCP 报文结构
      • TCP 连接管理
由 GitBook 提供支持
在本页
  • 技术架构
  • Name Server
  • Broker Server
  • Producer
  • Consumer
  • 部署架构
  • 主流 MQ 对比
  1. 中间件
  2. 消息队列

RocketMQ 架构设计

                  +----------------------------------------+
 Broker Discovery | +----------+ +----------+ +----------+ |      Broker Discovery
      +---------->| |NameServer| |NameServer| |NameServer| |<-----------+
      |           | +----------+ +----------+ +----------+ |            |
      |           +----------------------------------------+            |
      |                   ^    ^    ^    ^    ^    ^                    |
      |                   |    | routing info |    |                    |
      |                   v    v    v    v    v    v                    |
+------------+       +----------------------------------+         +------------+
| +--------+ |       | +------------+    +------------+ |         | +--------+ |
| |Producer| |       | |BrokerServer|    |BrokerServer| |         | |Consumer| |
| +--------+ |       | |   Master   |    |   Master   | |         | +--------+ |
|            |       | +------------+    +------------+ |         |            |
| +--------+ | send  |       ^                 ^        | receive | +--------+ |
| |Producer| |------>|       |     Data Sync   |        |-------->| |Consumer| |
| +--------+ |  msg  |       v                 v        |   msg   | +--------+ |
|            |       | +------------+    +------------+ |         |            |
| +--------+ |       | |BrokerServer|    |BrokerServer| |         | +--------+ |
| |Producer| |       | |   Slave    |    |   Slave    | |         | |Consumer| |
| +--------+ |       | +------------+    +------------+ |         | +--------+ |
+------------+       +----------------------------------+         +------------+

技术架构

RocketMQ 在架构设计上由四个部分组成:Name Server、Broker Server、Producer、Consumer。

Name Server

Name Server 是轻量化的 topic 注册中心,支持 Broker Server 的动态注册发现、路由信息的管理。Name Server 提供心跳检测机制,定时检查 Broker 是否存活。

Producer 和 Consumer 通过 Name Server 获取整个 Broker Server 集群的路由信息,从而进行消息的投递和消费。

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

Broker Server

Broker Server 负责消息的存储、投递、查询,以及保证服务的高可用,支持容错机制、灾备机制、报警机制和丰富的监控指标。

Broker Server 包含以下几个重要的子模块

  • Remoting Module 负责处理来自 client 的请求;

  • Client Manager 负责管理 Producer/Consumer 和维护 Consumer 的 topic 订阅信息;

  • Store Service 负责存储消息至磁盘、查询消息等功能;

  • HA Service 负责 Master Broker 和 Slave Broker 之间的数据同步;

  • Index Service 负责消息的索引服务,支持快速查询消息。

Producer

Producer 是发布消息的角色,通过多种负载均衡的方式,选择相应的 Broker Server 集群中的 Queue 发送消息。Producer 在发送消息时,支持快速失败,并且是低延迟的。

Consumer

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

部署架构

在 RocketMQ 集群部署过程中,各个部分有如下特点:

  • Name Server 集群之中的各个节点之间不会互相同步数据,各个节点近乎是无状态的;

  • Broker Server 集群支持以单 Master 多 Salve 模式部署,Master 与 Salve 的对应关系通过指定相同的 BrokerName 和不同的 BrokerId 来定义,BrokerId 为 0 表示 Master 节点,非 0 表示 Salve 节点。Broker Server 集群中的各个节点都会与 Name Server 集群之中的所有节点建立长链接,定时注册 topic 信息至所有 Name Server 节点中;

  • Producer 会随机与 Name Server 集群中的一个节点建立长连接,定期从 Name Server 获取 topic 路由信息,并会与 topic 所在的 Broker Server 的 Master 节点建立长连接,并且会定时向 Master 发送心跳。Producer 集群完全是无状态的,可以随意集群部署;

  • Consumer 会随机与 Name Server 集群中的一个节点建立长连接,定期从 Name Server 获取 topic 路由信息,并会与 topic 所在的 Broker Server 的 Master 和 Salve 节点建立长连接,并且会定时向 Master 和 Salve 发送心跳。Consumer 既可以从 Master 订阅消息,也可以从 Salve 订阅消息,Consumer 在获取消息的时候,Broker Server 的 Master 节点会根据获取消息的偏移量与最大偏移量的距离、服务器是否可读等因素建议 Consumer 下次是从 Master 或者 Salve 获取消息。

整体来看,RocketMQ 集群的工作流程如下:

  1. Name Server 启动之后,等待 Broker Server、Producer、Consumer 的连接。Name Server 相当于一个路由控制中心;

  2. Broker Server 启动之后,会与所有的 Name Server 建立长连接,定时发送心跳。心跳包中包含当前 Broker Server 的信息(ip + port 等),以及它所存储的所有 topic 信息。在 Broker Server 向 Name Server 注册成功之后,Name Server 中便有所有 topic 与 Broker Server 的映射关系;

  3. 在发送消息之前,会需要先创建 topic。在创建 topic 时,需要指定 topic 存储在哪台 Broker Server 上。RocketMQ 也支持在发送消息时自动创建 topic;

  4. Producer 启动之后会与 Name Server 集群中的一个节点建立长连接,并从 Name Server 确定待发送消息的 topic 所在的 Broker Server 节点,然后轮训从 queue 列表中选择一个 queue,并与该 queue 所在的 Broker Server 建立长连接,最后向该 Broker Server 发送消息;

  5. Consumer 与 Producer 类似,会与 Name Server 集群中的一个节点建立长连接,并从 Name Server 获取已订阅的 topic 所在的 Broker Server 节点,然后与该 Broker Server 建立长连接,最后开始消费消息。

主流 MQ 对比

RocketMQ
Kafka
RabbitMQ

单机 TPS

11.6w/s 吞吐量高

17.3w/s 吞吐量高

5.95w/s 实现 AMQP 协议,舍弃吞吐量,保证可靠性

持久化

磁盘(支持大量堆积)

内存、磁盘、数据库(支持大量堆积)

内存、磁盘

消息可靠性

高

一般

高

事务消息

支持

支持

支持

消息重试

支持

不支持

支持

定时消息

支持

不支持

不支持

消息加密

不支持

SSL

SSL

查询消息轨迹

支持

不支持

不支持

消息回溯

支持指定时间点回溯

支持队列 offset 回溯

不支持

最后更新于1年前