设计理念
RocketMQ设计是基于主题的发布和订阅模式，核心的功能主要包括消息发送、消息的存储(Broker)、消息消费，整天设计的话追求简单和性能第一，把一些特殊的场景留给后端开发使用者去实现。
可以看一下这三方面:
1."注册中心"。没有使用业界常用的zookeeper来充当路由信息管理的注册中心，而是自研了一个NameServer，来实现topic路由信息等其他信息的管理。他的Topic路由信息无须在集群中保持强一致性，只要最终一致性就可以了。NameServer之间不用通信，可以降低实现的复杂程度，对网络的要求也降低了不少，而且性能对比zookeeper还更好。
- IO存储几只。RocketMQ设计追求消费发送的高吞吐量，因此他把存储文件设计成了文件组的方式，每个文件大小相同固定，适合引入内存映射机制，写入时，所有主题的消息存储都基于顺序写，可以极大的提高写性能，并且为了兼顾消息消费和查找的性能，还引入了索引文件和消息消费队列文件保证顺序消费。
3.设计缺陷的容忍度。rocketMQ对消息的消费设计是，保证不会丢失消费，并且至少消费一次。对于使用者来说，可能需要保证一定被消费，并且只消费一次，这种场景，她的设计只会保证会被消费，降低了设计实现难度，可以专注保证消息发送的高可用，也给了使用者设计的空间留了余地，可以在消费时实现幂等。
一些基本功能的支持与如何实现
消息过滤
消息过滤就是指在消息消费时，消费者可以对同一主题下的消息按照规则去过滤，去消费自己想要的信息。
对此，RocketMQ对消息过滤提供了两种方式的支持：
1.在服务端的消息过滤机制。也就是在Broker端过滤，Broker只将消息消费者感兴趣消息。
2.消息在消费段过滤，过滤方式会由消息消费者去自定义，但是这种方式是有很多无用的消息会从broker传到消费端。
顺序消息
意思就是说消息消费者按照消息达到消息存储服务器的顺序消费，RocketMQ可以严格保证消息有序。
消息存储方面
消息中间件的一个核心实现是消息的存储对消息存储一般有如下两个维度的考量：
消息堆积能力和消息存储性能。RocketMQ 追求消息存储的高性能，引人内存映射机制，所有主题的消息顺序存储在同一个文件中。同时为了避免消息无限在消息存储服务器中累积，引入了消息文件过期机制与文件存储空间报警机制。
保证消息的高可用性
通常影响消息可靠性的有以下几种情况。
1 ) Broker 正常关机。
- Broker 异常Crash 。
- OS Crash 。
4 ）机器断电，但是能立即恢复供电情况。
5 ）机器无法开机（可能是CPU 、主板、内存等关键设备损坏） 。
6 ）磁盘设备损坏。
针对上述情况，情况1~4 的RocketMQ 在同步刷盘机制下可以确保不丢失消息，在异
步刷盘模式下，会丢失少量消息。情况5-6 属于单点故障，一旦发生，该节点上的消息全部丢失，如果开启了异步复制机制， RoketMQ 能保证只丢失少量消息， RocketMQ 在后续版本中将引人双写机制，以满足消息可靠性要求极高的场合。
消息到达（ 消费）如何实现低延迟
RocketMQ 在消息不发生消息堆积时，以长轮询模式实现准实时的消息推送模式。
如何确保消息必须被消费一次
RocketMQ 通过消息消费确认机制（ACK）来确保消息至少被消费一次，但由于ACK 消息有可能丢失等其他原因， RocketMQ 无法做到消息只被消费一次，有重复消费的可能。
如何实现回溯消息
回溯消息是指消息消费端已经消费成功的消息，由于业务要求需要重新消费消息。
RocketMQ 支持按时间回溯消息，时间维度可精确到毫秒，可以向前或向后回溯。
如何进行消息堆积
消息中间件的主要功能是异步解锢，必须具备应对前端的数据洪峰，提高后端系统的
可用性，必然要求消息中间件具备一定的消息堆积能力。RocketMQ 消息存储使用磁盘文件（内存映射机制），并且在物理布局上为多个大小相等的文件组成逻辑文件组，可以无限循环使用。RocketMQ 消息存储文件并不是永久存储在消息服务器端，而是提供了过期机制，默认保留3 天。
关于定时消息的支持
定时消息是指消息发送到Broker 后， 不能被消息消费端立即消费，要到特定的时间点
或者等待特定的时间后才能被消费。如果要支持任意精度的定时消息消费，必须在消息服务端对消息进行排序，势必带来很大的性能损耗，故RocketMQ 不支持任意进度的定时消息，而只支持特定延迟级别。
是否支持消息重试机制
消息重试是指消息在消费时，如果发送异常，消息中间件需要支持消息重新投递，
RocketMQ 支持消息重试机制。
摘自《RocketMQ技术内幕实现》阿里巴巴推荐
网友评论