设计理念
RocketMQ基于主题的发布和订阅模式。其核心功能包括消息发送、消息存储(Broker)、消息消费。性能体现在三个方面:
- NameServer设计简单,摒弃Zookeeper当注册中心。从实际需求出发,Topic路由信息无需在集群之间保持强一致,基于此,RocketMQ的NameServer集群之间互不通信,降低NameServer的复杂度,网络要求也降低不少,性能相比ZooKeeper提升很大
- 高效的IO存储机制。RocketMQ的消息存储文件大小固定(方便引入内存映射机制,因为内存映射大小不能超过1.5G,RocketMQ单个存储文件大小为1G),所有消息基于顺序写(磁盘顺序写效率很高),同时引入消息消费队列文件和索引文件(加快查找)。
- 容忍设计缺陷。中间件的难题:如何保证消息一定能被消费者消费,并且保证只消费一次。RocketMQ只能保证消息被消费者消费,不能保证只被消费一次。这样简化了消息中间件的内核。消息重复问题由消费者在消费消息时实现幂等
设计目标
RocketMQ需要解决一下问题:
-
架构模式
RocketMQ采用发布订阅模式,基本组件:消息发送者,消息服务器(消息存储),消息消费,路由发现
-
顺序消息
顺序消息,指消息消费者按照消息到达消息存储服务器的顺序消费,RocketMQ可以严格保证消息有序
-
消息过滤
消息过滤,指消息消费时,消息消费者可以对同一主题下的消息按照规则只消费自己感兴趣的消息。RocketMQ消息过滤支持在服务端和消费端的消息过滤机制
消息在Broker端过滤。Broker只将消息消费者感兴趣的消息发送消息消费者
消息在消息消费端过滤。过滤方式由消费者自定义,缺点是无用的消息会从Broker传输到消费端
-
消息存储
核心实现是消息存储,两个维度考量:消息堆积能力和消息存储性能。引入消息文件过期机制和文件存储空间报警机制避免消息无限在消息存储服务器中累积。引入内存映射机制和顺序写提升消息存储性能
-
消息高可用性
消息可靠性通常有以下几种情况:
1)Broker正常关机
2)Broker异常Crash
3)OS Crash
4)机器断电,但是能立即恢复供电
5)机器无法开机
6)磁盘设备损坏
情况14的RocketMQ在同步刷盘机制下可以确保不丢失消息,在异步刷盘模式下,会丢失少量消息。清空56属于单点故障,一旦发生,该节点消息全部丢失,若开启异步复制,会丢失少量消息
-
消息到达(消费)低延迟
RocketMQ在消息不发生堆积时,以长轮询模式实现准实时的消息推送模式
-
确保消息必须被消费一次
RocketMQ通过消息确认机制(ACK)来确保消息至少被消费一次(由于ACK消息有可能丢失等原因,无法做到只被消费一次)
-
回溯消息
回溯消息,指已经消费成功但需要重新消费的消息。RocketMQ支持按时间回溯消息,时间维度可精确到毫秒,可向前或向后回溯
-
消息堆积
RocketMQ消息存储使用磁盘文件,在物理布局上为多个大小相等的文件组成逻辑文件组,可以无限循环使用。RocketMQ消息存储提供过期机制,默认保留3天
-
定时消息
定时消息,指消息发送到Broker后,不能被消费端立即消费,要到特定的时间点或等待特定的时间后才能被消费。RocketMQ只支持特定延迟级别。若支持任意精度的定时消费,必须在消息服务端对消息进行排序,性能损耗很大
-
消息重试机制
消息重试,指消息在消费时,如果发送异常,消息中间件支持消息重新投递,RocketMQ支持消息重试机制