RocketMq的设计是基于主题的发布与订阅模式，其核心功能包括消息发送、消息存储、消息消费，整体设计追求简单与性能第一。
首先，nameserver的设计极其简单，摒弃了业界常用的zookeeper充当信息管理的“注册中心”，而是自研nameserver来实现元数据的管理（topic路由等信息）。从实际需求出发，因为topic路由信息无需在集群之间保持强一致性，追求最终一致性，并且能容忍分钟级别不一致。正是基于这种情况，RocketMq的nameserver集群之间互不通信，极大的降低了nameserver实现复杂度，对于网络的要求也降低了多少，但是性能相比较zookeeper有了极大的提升。
其次，高效的IO存储机制。RocketMq追求消息发送的高吞吐量，RocketMq的消息存储文件设计成文件组模式，组内单个文件大小固定，方便引入内存映射机制，所有的消息存储基于顺序写，极大地提升了消息写性能，同时为了兼顾消息消费与查找，引入了消息消费队列与索引文件。
最后，容忍设计缺陷。消息中间件的使用者经常遇到一个难题：如何保证消息一定被消息消费者消费，并且保证只能被消费一次。RocketMq的设计者给出的解决办法是不解决这个问题，而是退而求其次，只保证消息被消费者消费，但是设计上允许消息重复消费。这样就极大了简化了消息中间件的内核，使用消息的发送高可用变得非常简单和高效，消息重复消费问题由消费者在消息消费时实现幂等。
2. 设计目标架构模式
发布订阅模式，组件包括：消息发送者、消息服务器、消息消费、路由发现
顺序消息
消费消息的顺序同存储到队列的顺序一致（队列内有序）
消息过滤
消息过滤是指在消息消费时，消息消费者可以统一主题下的消息按照规则只消息自己感兴趣的消息。RocketMq消息过滤支持在服务端与消费端的消息过滤机制。
- broker端过滤。broker只将消息消费者感兴趣的消息发送给消息消费者消息在消息消费者端过滤。消息过滤方式完全由消息的消费者自己定义，但是会导致很多无用的消息会从broker传输到消费端
消息存储
消息堆积和消息存储性能。追求消息存储的高性能，引入内存映射机制，所有的主题的消息顺序存储在同一个文件中。同时为了避免消息无限在消息存储服务器中累计，引入了消息文件过期机制与文件存储空间报警机制。
消息的高可用性
- broker正常关机broker异常crashos crash机器断电，但是能立即恢复供电情况机器无法开机磁盘设备损坏
14采用同步刷盘机制可以确保不丢失消息，在异步刷盘模式下，情况1不会丢失消息，情况24会丢失少量消息。5~6属于单点故障，一旦发生故障，该节点上的消息全部丢失，如果开启了异步复制机制，rocketmq能保证只丢失少量消息，rocketmq在后续版本中将引入多副本机制，以满足消息可靠性要求极高的场合。
消息到达的低延迟
消息不发生消息堆积的时候，采用长轮询模式实现准实时消息推送模式
确保只被消费一次
通过采用ACK机制确保消息至少被消费一次，但是由于ACK消息存在丢失的可能，无法做到只被消费一次，有重复消费的可能。
回溯消息
回溯消息是指在消息消费端消费成功的消息，由于业务要求需求重新消费消息，支持按照时间回溯消息，文件维度可以精确到毫秒
消息堆积
消息存储采用磁盘文件（内存映射机制），并且在物理布局上为多个大小相等的文件组成的逻辑组，可以无限循环使用。但是rocketmq消息存储文件并不是永久存储在消息服务器端，而是提供了过期机制，默认保留三天。
定时消息
消息发送到broker之后，不能被消息端立即消费，要到指定时间点或者特定的时间后才能被消费。如果要支持任意精度的定时消息消费，必须在消费服务端对消息进行排序，势必会带来很大的性能损耗。
消息重试机制
消息重试是指消息在消费时，如果发生异常时，消息中间件需要支持消息重新投递。
