一.目录结构
1)broker:broker模块
2)client:消息客户端,包含消息生产者,消费者相关类
3)common:公共包
4)dev:开发者信息(非源代码)
5)distribution:部署实例文件夹(非源代码)
6)example:rocketmq示例文件
7)filter:消息过滤相关基础类
8)filtersrv:消息过滤服务器实现相关类(Filter启动进程)
9)logappender:日志实现相关类
10)namesrv:NameServer实现相关类
11)openmessaging:消息开放标准
12)remoting:远程通信模块
13)srvutil:服务器工具类
14)store:消息存储实现相关类
15)style:checkstyle相关实现
16)test:测试相关类
17)tools:工具类,监控命令相关实现类
二.设计理念与目标
2.1设计理念
基于主题的发布订阅模式,核心包括消息发送,消息存储,消息消费,追求简单和性能第一
NameServer设计简单,摒弃了Zookeeper充当注册中心,采用自研NameServer实现元数据的管理(Topic路由信息),追求最终一致性,Rocketmq的Nameserver集群间互不通信,极大地降低了NameServer实现的复杂程度,对网络的要求也降低不少,性能相对于Zookeeper有较大提升
高效的IO存储机制,Rocketmq追求消息发送的高吞吐量,消息存储文件设计成文件组的概念,组内单个文件大小固定,方便引入内存映射机制,所有肢体的消息存储基于顺序写,为了兼顾消息消费与消息查找,引入了消息消费队列文件与索引文件
容忍存在设计,Rocketmq未解决重复消费,简化中间件的内核使得实现消息发送高可用变得简单高效
2.2设计目标
架构模式
和大部分消息中间件一样,采用发布订阅模式, 组件有:发送者 消息服务器(消息存储) 消息消费 路由发现
顺序消息
按着到达消息存储服务器的顺序消费
消息过滤
在服务端和消费端过滤
消息存储
消息中间件一个核心实现是消息的存储,对消息存储一般有如下两个维度的考虑:消息堆积能力和消息存储能力,RocketMq追求消息存储的高性能,引入内存映射机制,所有主题的消息顺序存储在同一个文件中,为了避免无限在消息服务器中累积,引入了消息文件过期机制与文件存储空间报警机制
消息高可用
通常有以下几种情况影响消息可靠性
1)Broker正常关机
2)Broker异常Crash
3)OS Crash
4)机器断点,但能立即恢复供电
5)机器无法开机
6)磁盘损坏
情况1-4的Rocketmq在同步刷盘急之下可以确保不丢失消息,在异步刷盘模式下,会丢少量消息,5-6属于单点故障,一旦发生,该节点的消息全部丢失
消息到达低延迟
采用长轮询模式实现准实时的消息推送模式
确保消息必须被消费一次
通过消息消费确认机制ACK确保消息至少被消费一次,但是由于ACK消息可能丢失等其他原因,Rocketmq无法做到只消费一次
回溯消息
消息消费端已经消费成功的消息,可以重新消费
消息堆积
Rocketmq消息存储使用磁盘文件(内存映射机制),在物理布局上为多个大小相等的逻辑文件组,可以无限使用,消息存储文件默认保留3天
定时消息
定时消息是指发送到Broker后,不能被消费端立即消费,要到特定时间或者等待特定时间后才能被消费,如果要支持任意经度的定时消息消费,服务端需对消息进行排序,势必带来很大的性能消耗,所以rocketmq不支持任意进度的定时消息,只支持特定延迟级别
消息重试机制
当消息在消费时出现异常,消息中间件需要重新投递
