RocketMQ概论

目录

前言：

1.概述

2.下载安装、集群搭建

3.消息模型

4.如何保证吞吐量

4.1.消息存储

4.1.1顺序读写

4.1.2.异步刷盘

4.1.3.零拷贝

4.2.网络传输

---

前言：

RocketMQ的代码示例在安装目录下有全套详细demo，所以本文不侧重于讲API这种死的东西，而是侧重于讲解RocketMQ的特性。消息中间件无非需要关注三点：吞吐量、消息可靠性、消息模型。任何消息中间件的异同点就体现在这三个方面。本文也会从这三个方面来讲解RocketMQ。

本文是作者RocketMQ系列文章的最后一篇，一些基础的概念、下载安装、集群、基本消息模型等，前面都已经有单独的文章讲过，每篇都很深入浅出，单篇阅读花不了两三分钟，所以这些内容会直接贴上链接。

1.概述

RocketMQ 是一款开源的分布式消息中间件，最初由阿里巴巴集团开发并开源。它旨在为分布式系统提供可靠、高性能、可扩展的消息通信能力。RocketMQ和RabbitMQ、KAFKA一起并列为现在主流的三大消息中间件。

RocketMQ的基本概念+架构：

RocketMQ基础概念__BugMan的博客-CSDN博客

2.下载安装、集群搭建

RocketMQ的下载安装教程+集群搭建教程：

RocketMQ下载安装、集群搭建保姆级教程_安装rocketmq集群__BugMan的博客-CSDN博客

3.消息模型

RocketMQ的消息模型有以下几种：

• 顺序消息，消费者按照生产者的发送顺序进行消费。
• 广播消息，一条消息被多个消费者消费。
• 延迟消息，驻留时间，消费者才能消费到消息。
• 批量消息，支持生产者批量发送消息。
• 过滤消息，通过tag，消费者可以消费同一个topic下自己感兴趣的消息。
• 事务消息，生产者的消息生产支持事务回退。

RocketMQ消息模型详解：

详解RocketMQ使用__BugMan的博客-CSDN博客

4.如何保证吞吐量

4.1.消息存储

RocketMQ最大的特点概括起来其实就一句话：

既保证了消息的可靠性，又保证了吞吐量。

可靠性和吞吐量其实是互斥的两点，为了保证可靠性，消息就一定要落在磁盘存储防止断电丢失。落在磁盘存储后，读这条消息的时候的磁盘IO就会拉低吞吐量。所以RocketMQ的核心其实就是数据落磁盘，然后想尽一切办法来提高吞吐量。

RocketMQ的生产消费过程：

• 收到生产者发送的消息，将其存起来

• 向消费者推送一条消息后，等待消费者的ACK，收到ACK后将消息标记为已消费。

• 定期删除一些已经过期的消息。

RocketMQ用来提高吞吐量的手段：

• 顺序写

• 异步刷盘

• 零拷贝

4.1.1顺序读写

磁盘的顺序读写性能要远好于随机读写。因为每次从磁盘读数据时需要先寻址，找到数据在磁盘上的物理位置。对于机械硬盘来说，就是移动磁头，会消耗时间。 顺序读写相比于随机读写省去了大部分的寻址时间，它只需要寻址一次就可以连续读写下去，所以性能比随机读写好很多。

RocketMQ 利用了这个特性。它所有的消息数据都存放在一个无限增长的文件队列 CommitLog 中，CommitLog 是由一组 1G 内存映射文件队列组成的。 写入时就从一个固定位置一直写下去，一个文件写满了就开启一个新文件顺序读写下去。

RocketMQ顺序写盘的过程如下：

1. 生产者发送消息到 RocketMQ Broker。Broker 接收到消息后，将消息按照顺序写入内存中的 Page Cache（页面缓存）中。

2. 消息在内存的 Page Cache 中形成连续的数据块。由于 RocketMQ 的顺序写盘策略，相同 Topic 和 Queue ID 的消息会按照发送的先后顺序排列成一批，形成连续的数据块，而不是随机地散落在磁盘上。

3. 然后，后台线程会定期将 Page Cache 中的连续数据块顺序写入磁盘上的存储文件中，称为 "CommitLog"。由于数据是连续写入，因此磁盘的写入操作变得高效，减少了寻道时间和磁盘的碎片化，提高了写入性能。

需要注意的是，顺序写盘并不是说所有消息都按照先后顺序写入，而是相同 Topic 和 Queue ID 的消息会按照发送的先后顺序形成连续的数据块写入磁盘。对于不同 Topic 和 Queue ID 的消息，它们可能在磁盘上是交错存储的。

4.1.2.异步刷盘

RocketMQ 的异步刷盘（Async Flush）是一种优化手段，用于提高消息的写入性能和吞吐量。在消息存储上，RocketMQ 遵循了写入先落盘再返回的策略，即在消息写入磁盘之前，会先将消息写入操作系统的 Page Cache（页面缓存）中，并立即返回写入成功的响应给生产者，然后由后台线程异步地将 Page Cache 中的数据刷写到磁盘中。

4.1.3.零拷贝

零拷贝（Zero-Copy）是一种优化技术，旨在提高数据传输的效率和性能，特别是在文件传输和网络数据传输中。传统的数据传输方式涉及多次数据拷贝，而零拷贝通过避免不必要的数据拷贝操作，减少了数据传输的开销，从而提高系统的性能。

在传统的数据传输中，例如从磁盘读取文件并通过网络发送，通常涉及以下步骤：

1. 将数据从磁盘读取到内核空间（Kernel Buffer）。
2. 将数据从内核空间拷贝到用户空间（User Buffer）。
3. 将数据从用户空间拷贝到网络缓冲区（Network Buffer）。
4. 最终数据通过网络发送。

这种传统的数据传输方式涉及多次数据拷贝，每次拷贝都需要 CPU 参与，并且需要在内核空间和用户空间之间进行数据复制，导致了额外的开销和延迟。

零拷贝技术的主要思想是避免不必要的数据拷贝，通过直接在内核空间和用户空间之间传输数据，从而减少 CPU 和内存的使用。

关于0拷贝更详细的内容异步博主的另一篇文章：

全网最清晰的零拷贝详解，看一遍就会__BugMan的博客-CSDN博客

4.2.网络传输

关于序列化，以及为什么要用序列化，不是很清楚的同学可以移步博主的另一篇文章：

详解JAVA序列化__BugMan的博客-CSDN博客

RocketMQ的报文使用了序列化，序列化和反序列化由生产者端和消费者端的SDK来实现。

RocketMQ目前支持的序列化方式有：

1. RocketMQ 自定义序列化：RocketMQ 使用自定义的序列化协议进行消息的编码和解码。这个序列化协议被称为 Remoting Command Protocol。该协议采用了二进制格式，对消息进行高效的编解码处理，以实现高性能和低延迟。

2. JSON 序列化：RocketMQ 支持将消息转换为 JSON 格式进行传输。JSON 序列化方式适合处理复杂结构的消息，易于阅读和调试，但相比二进制格式会增加一定的传输开销。

3. Java 原生序列化：RocketMQ 还支持使用 Java 原生的序列化方式（Java Serialization）。Java 原生序列化是 Java 标准库提供的一种序列化方式，但在性能方面可能不如其他序列化框架。

4. Hessian 序列化：Hessian 是一种二进制序列化框架，支持多种编程语言。RocketMQ 支持使用 Hessian 将消息序列化为二进制数据进行传输。