这是我参与更文挑战的第4天，活动详情查看： 更文挑战
前言
今天是分享rocketMq的第一篇，万事开头难，在思考要做rocketMq源码系列分享后，我考虑了到底是按照哪个版本来分享，当前公司使用的是阿里云收费版，而收费版跟开源版相对还是有些差异的，由于阿里收费版的源码没法搞到，所以后续的分享都是基于其开源版本来做的。 这里简要说一下开源版跟收费版本的一些差异：
1、收费版本是支持秒级的延迟消息，而开源版本只支持18个级别的延迟消息，当然你要想搞就需要在源码的基础上二次开发
2、收费版与开源版的批量消息的兼容问题，这个是来自阿里云的开发者的反馈
目录
1、rocketmq是什么
2、rocketmq源码地址与核心目录
3、rocketmq的设计理念
4、rocketmq的设计目标
5、后续的分享规划
一、rocketmq是什么？
1、是一个队列模型的消息中间件，具有高可用、高实时、分布式特点
2、Producer、Consumer、Broker、 NameServer都可以分布式。
3、实时的消息订阅机制
4、亿级消息堆积能力等
二、rocketmq源码地址与核心目录
源码地址： github.com/apache/rock…
官网地址： rocketmq.apache.org/
目录结构如图
1、broker：broker模块，消息服务器
2、client：消息客户端，包括消息生产者，消息消费者
3、common：公共包
4、filter：消息过滤相关基础类
5、filtersrv：消息过滤服务器实现相关类（Filter启动进程）
6、namesrv：NameServer实现相关类（NameServer启动进程）
7、openmessaging：消息开放标准（阿里积极推进中）
8、remoting：远程通信模块（基于Netty）
9、store：消息存储实现相关类
10、test：测试相关
11、tools：工具类，监控命令相关
三、rocketmq的设计理念
rocketMq的设计是基于主题（topic）的发布订阅模式，其核心功能包括消息发送，消息存储（broker处理），消息消费，整体设计追求结构简单与性能第一，其具体特点体现在了如下几个方面：
1、注册中心（NameServer）设计极其精简，并没有选择业界主流的注册中心，如zookeeper、eureka、nacos(这个出现比较晚)等作为自己的注册中心，而是自研NameServer来进行元数据的管理（topic路由信息等）。例如zk是一个标准的cp系统，即保持数据的强一致性，而rocketMq从自身实际需求出发，因为topic路由信息无需在集群中保持强一致性，而追求的是最终一致性，并且能够容忍分钟级的不一致，基于这种情况，rocketMq的nameServer集群的节点之间是相互不通信的，这就极大的降低了nameServer设计的复杂度，并且对网络的要求也降低了不少，但是性能上却相比zk有了极大的提升（像惊群效应就不会出现）。
2、高效的IO存储机制，rocketMq为了追求高吞吐量的消息发送，而将消息存储文件设计成了文件组的概念，组内的单个文件大小固定，这样方便引入内存映射机制，并且所有主题的消息都是基于顺序写（固态硬盘的顺序写速度通常在450MB/s~600MB/s之间），极大的提高了消息写的性能，同时为了兼顾消息消费与查找引入了消息消费队列文件与索引文件（这是我认为rocketMq设计比较巧妙的地方）
3、容忍设计缺陷，所谓不完美的即是最完美。rocketMq适当的将一些工作下放给了使用者来实现。消息中间件的实现往往会遇到这样一个难题，即如何保证消息会被消费，并且只被消费一次。rocketMq提供的设计思路是，不解决这个难题，而是退而求其次，只保证消息会被消费，但是有可能会被重复消费，而保证消息幂等性的问题则交给使用者来实现，这样的设计极大的简化了消息中间件的内核，使得实现消息发送与消费的高可用变得非常简单与高效。
四、rocketmq的设计目标
1、架构模式： 采用发布订阅模式，基本组件包括：消息发送者、消息服务器（消息存储）、消息消费、路由发现
2、顺序消息： 顺序消息，即消息消费者严格按照消息到达消息存储服务器的顺序消费，rocketMq严格保证消息有序
3、消息过滤： 消息过滤是指消息消费者可以将同一topic下的消息按照规则只消费自己感兴趣的消息，rocketMq的消息过滤支持在服务端与消费端的消息过滤机制，在服务端（broker）过滤，只将满足规则的消息发送给消息消费者；在消息消费端过滤，过滤方式完全由消息消费者自定义，但缺点会接收很多无用消息
4、消息存储： 消息中间件的一个核心实现就是消息的存储，对于消息的存储一般有两个维度的考量：消息的堆积能力和消息的存储性能。rocketMq追求消息存储的高性能，引入了内存映射机制，所有主题的消息顺序的存储在同一文件中，而关于消息堆积，为了避免消息无限的在服务器中积累，引入了消息文件过期机制与文件存储空间报警机制。
5、消息高可用性： 通常影响高可用性的有下列几种情况：1、broker正常关机；2、broker异常crash；3、OS crash；4、机器断电但能立即供电；5、机器无法开机（主板、CPU、内存等关键硬件损坏）；6、磁盘设备损坏。针对1~4的情况，rocketMq在同步刷盘的机制下可以确保不丢失消息，在异步刷盘的机制下，会丢失少量消息。情况5、6属于单点故障，该节点的消息将全部丢失，若是开启了异步同步机制，则可保证只丢失少量消息，双写机制则可满足这种可靠性极高的场合
6、消息到达（消费）低延迟： rocketMq在不发生消息堆积的情况下，以长轮询的方式实现准实时的消息推送
7、保证消息至少被消费一次： rocketMq通过消息消费确认机制（ACK）来确保消息至少被消费一次，但是由于ACK消息有可能丢失等其他原因，rocketMq无法做到消息只被消费一次，可能存在重复消费
8、回溯消息： rocketMq支持按照时间维度回溯消息，时间维度可精确到毫秒，向前或者向后回溯
9、消息堆积： rocketMq消息存储采用的是磁盘文件（内存映射机制），在物理布局上为多个大小相等的文件组成逻辑文件组，可以无限循环使用，但是消息并不是永久的存储在消息服务器中，而是提供了过期机制，默认是消息保存3天
10、定时消息（延时消息）： 定时消息是指消息被发送到消息服务器端（broker）后，不能被消息消费者立即消费，而是等到特定的时间点或者特定的时间后才会被消费。开源版的rocketMq不支持任意进度的定时消息，只支持特定的延时级别（18个级别），阿里云的mq已经支持秒级别的延迟，只能说有钱能使鬼推磨
11、消息重试机制： 消息重试是指在消息在消费时，发生发送异常，支持消息重新投递，rocketMq支持消息重试
五、后续的分享规划
1、路由中心NameServer
2、消息发送
3、消息存储
4、消息消费
5、事物消息与主从机制
6、日常开发问题与实战
The End
喜欢点个赞，真的对我很重要。每日更新，持续输出。
