1.3　RocketMQ的设计理念和设计目标

1.3.1　设计理念

RocketMQ设计基于主题的发布与订阅模式，其核心功能包括消息发送、消息存储和消息消费，整体设计追求简单和性能高效，主要体现在如下3个方面。

首先，NameServer的设计极其简单，摒弃了业界常用的将ZooKeeper作为信息管理的“注册中心”，而是自研NameServer实现元数据的管理（topic路由信息等）。从实际需求出发，topic路由信息无须在集群之间保持强一致，而是追求最终一致性，并且能容忍分钟级的不一致。正是基于这种特性，RocketMQ的NameServer集群之间互不通信，这样极大地降低了NameServer实现的复杂度，对网络的要求也降低了不少，性能相比较ZooKeeper还有了极大的提升。

其次是高效的I/O存储机制。RocketMQ追求消息发送的高吞吐量，RocketMQ的消息存储文件被设计成文件组的概念，组内单个文件大小固定，方便引入内存映射机制，所有主题的消息存储按顺序编写，极大地提升了消息的写性能。同时为了兼顾消息消费与消息查找，引入了消息消费队列文件与索引文件。

最后是容忍存在设计缺陷，适当将某些工作下放给RocketMQ使用者。消息中间件的实现者经常会遇到一个难题：如何保证消息一定能被消息消费者消费，并且只消费一次？

RocketMQ的设计者给出的解决办法是不解决这个难题，而是退而求其次，只保证消息被消费者消费，在设计上允许消息被重复消费。这样极大地简化了消息中间件的内核，使得实现消息发送高可用变得非常简单和高效，消息重复问题由消费者在消息消费时实现幂等。

1.3.2　设计目标

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

1. 架构模式

RocketMQ与大部分消息中间件一样，采用发布订阅模式，主要参与组件包括：消息发送者、消息服务器（消息存储）、消息消费和路由发现。

2. 顺序消息

所谓顺序消息，就是消息消费者按照消息达到消息存储服务器的顺序消费。RocketMQ可以严格保证消息有序。

3. 消息过滤

消息过滤是指在消息消费时，消息消费者可以对同一主题下的消息按照规则只消费自己感兴趣的消息。RocketMQ消息过滤是由服务端和消费端共同完成的。

4. 消息存储

消息中间件的一个核心实现是消息的存储，对于消息存储一般有如下两个维度的考量：消息堆积能力和消息存储性能。RocketMQ追求消息存储的高性能，引入内存映射机制，所有主题的消息按顺序存储在同一个文件中。同时为了避免消息在消息存储服务器中无限地累积，引入了消息文件过期机制与文件存储空间报警机制。

5. 消息高可用性

通常影响消息可靠性的有以下几种情况。

1）Broker异常崩溃。

2）操作系统崩溃。

3）机器断电，但是能立即恢复供电。

4）机器无法开机（可能是CPU、主板、内存等关键设备损坏）。

5）磁盘设备损坏。

对于前3种情况，RocketMQ在同步刷盘模式下可以确保不丢失消息，在异步刷盘模式下，会丢失少量消息。后2种情况属于单点故障，一旦发生，该节点上的消息会全部丢失。如果开启了异步复制机制，RoketMQ能保证只丢失少量消息。

6. 消息到达（消费）低延迟

RocketMQ在消息不发生堆积时，以长轮询模式实现准实时的消息推送模式。

7. 确保消息必须被消费一次

RocketMQ通过消息消费确认机制（ACK）确保消息至少被消费一次，因为ACK消息有可能出现丢失等情况，RocketMQ无法做到消息只被消费一次，所以有重复消费的可能。

8. 回溯消息

回溯消息是指消息消费端已经消费成功，根据业务要求，需要重新消费消息。RocketMQ支持按时间向前或向后回溯消息，时间维度可精确到毫秒。

9. 消息堆积

消息中间件的主要功能是异步解耦，必须能应对前端的数据洪峰，提高后端系统的可用性，这必然要求消息中间件具备一定的消息堆积能力。RocketMQ使用磁盘文件存储消息（内存映射机制），并且在物理布局上为多个大小相等的文件组成逻辑文件组，可以无限循环使用。RocketMQ消息存储文件并不是永久存储在消息服务器端的，而是提供了过期机制，默认保留3天。

10. 定时消息

定时消息是指消息发送到Broker后，不能被消息消费端立即消费，而是要到特定的时间点或者等待特定的时间后才能被消费。因为如果要支持任意精度的定时消息消费，就必须在消息服务端对消息进行排序，这势必带来很大的性能损耗，所以RocketMQ不支持任意进度的定时消息，只支持特定延迟级别。

11. 消息重试机制

RocketMQ支持消息重试机制。消息重试是指在消息消费时如果发生异常，消息中间件支持消息重新投递。