《RocketMQ技术内幕》笔记

阅读源码的准备工作

获取和调用RocketMQ源码

IDEA获取RocketMQ源码

IDEA调试RocketMQ源码

RocketMQ目录结构

RocketMQ 核心目 录说明如下

1. broker: broker 模块（broke 启动进程）
2. client ：消息客户端，包含消息生产者、消息消费者相关类
3. common ：公共包
4. dev ：开发者信息（非源代码）
5. distribution ：部署实例文 夹（非源代码）
6. example: RocketMQ 例代码
7. filter ：消息过滤相关基础类
8. filtersrv 消息过滤服务器实现相关类（Filter 启动进程）
9. logappender ：日志 现相关类
10. namesrv : N ameServer 实现相关类（Names rver 启动进程）
11. openmessaging 消息开放标准，正在制定中
12. remoting 远程通信模块，基于 Netty
13. srvut ：服务器工具类
14. store ：消息存储实现 关类
15. style: checkstyle 相关实现
16. test: 测试相关类
17. toos 工具类 ，监控命令相关实现类

RocketMQ设计理念与目标

设计理念

RocketMQ 设计基于主题的发布与订阅 模式 其核心功能包括消息发送、 消息存储Broker ）、消息消费，整体设 追求简单与性能第一，主要体 在如下三个方面
首先， ameSe ver 设计极其简单，摒弃了业界常用的使用 Zoo keeper 当信息管理的“注册中心”，而是自研 NameServer 元数据 管理(Topic 路由信息等)。从实际需求出发，因为 Topic 路由信息无须在集群之间保持强一致，追求最终一致性，并且能容忍分钟级的不一致 正是基于此种情况 RocketMQ NameServer 集群之间互不通信，极大地降低了 NameSe ve 现的 复杂程度， 对网络的要求也降低了不少 性能相比较Zoo keeper 有了极大的提升。

设计目标

RocketMQ 作为一款消息中间件 ，需要解决如下问题

1. 架构模式：RocketMQ 与大部分消息中间件 样，采用发布订阅模式，基本的参与组件主要包括消息发送者、消息服务器（消息存储）、消息消费、路由发现
2. 顺序消患：所谓顺序消息，就是消息消费者按照消息达到消息存储服务器的顺序消费 RocketMQ可以严格保证消息有序
3. 消息过滤：消息过滤是指在消息消费时，消息消费者可以对同一主题下的消息按照规 ,只消费自己感兴趣的消息 RocketMQ 消息过滤支持在服务端与消费端的消息过滤机制
4. 消息存储：消息中间件的 个核心实现是消息的存储 对消息存储一般有如下两个维度的考量消息堆积能力和消息存储性能 RocketMQ 追求消息存储的高性能，引人内存映射机制，所有主题的消息顺序存储在同一个文件中 同时为了避免消息无限在消息存储服务器中累积，引入了消息文件过期机制与文件存储空间报警机制
5. 消息 可用性：Broker 正常关机，Broker 异常 Crash，OS Crash，机器断电，但 能立即恢复供电情况，机器无法开机（可能是 CPU 、主板、 内存等关键设备损坏），磁盘设备损坏情况时。情况 1~4 RocketMQ 在同步刷盘机制下可以确保不丢失消息，在异步刷盘模式下，会丢失少量消息 情况 5-6 属于单点故障，一旦发生，该节点上的消息全部丢失，如果开启了异步复制机制， RoketMQ 能保证只丢失少量消息， RocketMQ 在后续版本中将引人双写机制，以满足消息可靠性要求极高的场合
6. 消息到达(消费) 低延迟：RocketMQ 在消息不发生消息堆积时，以长轮询模式实现准实时的消息推送模式
7. 确保消息必须被消费一次：RocketMQ 通过消息消费确认机制（ACK）来确保消息至少被消费一次 ，但由于 ACK消息有可能丢失等其他原因， RocketMQ 无法做到消息只被消费 次，有重复消费的可能
8. 回溯消息：回溯消息是指消息消费端已经消费成功的消息，由于业务要求需要重新消费消息。RocketMQ 支持按时间回溯消息，时间维度可精确到毫秒，可以向前或向后回溯
9. 消息堆积：消息中间件的主要功能是异步解锢，必须具备应对前端的数据洪峰，提高后端系统的可用性，必然要求消息中间件具备 定的消息堆积能力 RocketMQ 消息存储使用磁盘文件（内存映射机制），并且在物理布局上为多个大小相等的文件组成逻辑文件组，可以无限循环使用；RocketMQ 消息存储文件并不是永久存储在消息服务器端，而是提供了过期机制，默认保留
10. 定时消息：定时消息是指消息发送到 Broker 后， 不能被消息消费端立即消费，要到特定的时间点或者等待特定的时间后才能被消费 如果要支持任意精度的定时消息消费，必须在消息服务端对消息进行排序，势必带来很大的性能损耗，故 RocketMQ 不支持任意进度的定时消息，而只支持特定延迟级别。
11. 消息重试机制：消息重试是指消息在消费时，如果发送异常，消息中间件需要支持消息重新投递，RocketMQ 支持消息重试机制

RocketMQ 路由中心 NameServer

本章主要介绍 RocketMQ 路由管理 服务注册及服务发现的机制， NameServer 是整个RocketMQ 的“大脑” 相信大家对“服务发现”这个词语并不陌生，分布式服务 SOA 架构体系中会有服务注册中心，分布式服务 SOA 的注册中心主要提供服务调用的解析服务，指引服务调用方（消费者）找到“远方”的服务提供者，完成网络通信，那么 RocketMQ 的路由中心存储的是什么数据呢？作为一款高性能的消息中间件，如何避免 NameServer 的单点故障，提供高可用性呢？让我们带着上述疑问， 起进入 RocketMQ NameServer 的精彩世界中来

NameServer 架构设计

消息中间件的设计思路 般基于主题的订阅发布机制 消息生产者（ Producer ）发送某 主题的消息到消息服务器，消息服务器负责该消息的持久化存储，消息消费者(Consumer）订阅感兴趣的主题，消息服务器根据订阅信息（路由信息）将消息推送到消费者（ PUSH 模式）或者消息消费者主动向消息服务器拉取消息（ PULL 模式），从而实现消息生产者与消息消费者解调 为了避免消息服务器的单点故障导致的整个系统瘫痪，通常会部署多台消息服务器共同承担消息的存储 那消息生产者如何知道消息要发往哪台消息服务器呢？如果某一台消息服务器若机了，那么生产者如何在不重启服务的情况下感知呢？

• Broker 消息服务器在启动时向所有 Name Server 注册，消息生产者（Producer）在发送消息之前先从 Name Server 获取 Broker 服务器地址列表，然后根据负载算法从列表中选择一台消息服务器进行消息发送 NameServer 与每台 Broker 服务器保持长连接，并间隔 30s 检测Broker 是否存活，如果检测到 Broker 从路由注册表中将其移除 但是路由变化不会马上通知消息生产者，为什么要这样设计呢？这是为了降低 NameSe ve 实现的复杂，在消息发送端提供容错机制来保证消息发送的高可用性。
• NameServer 本身的高可用可通过部署多台 Names rver 服务器来实现，但彼此之间互不通信，也就是 NameServer 务器之间在某一时刻的数据并不会完全相同，但这对消息发送不会造成任何影响，这也是 RocketMQ NameServer 设计的 一个亮点， RocketMQNameServer 计追求简单高效

NameServer 启动流程

从源码的角度窥探一 Names rver 启动流程，重点关注 NameServer 关启动参数

1. NameServer 启动 org .apache.rocketrr name srv.Na esrvS tartup