RocketMQ 学习笔记02-RocketMQ架构方案

1.设计理念

2.设计目标

2.1.架构模式

RocketMQ 与大部分消息中间件同样，采用发布订阅模式，基本的参与组件包括：消息发送者、消息服务器、消息消费、路由发现。

2.2.顺序消息

所谓顺序消息，就是消息消费者按照消息到达消息存储服务器的顺序消费。RocketMQ 能够保证消息严格有序。

2.3.消息过滤

消息过滤是指在消费消息时，消息消费者能够对同一主题下的消息按照规则只消费本身感兴趣的消息。RocketMQ 消息过滤支持在服务端与消费者端的消息过滤机制。

• 1.消息在broker 端过滤。broker 只将消息消费者感兴趣的消息发送给消息消费者。
• 2.消息在消费者端过滤，消息过滤方式彻底有消费者自定义，缺点是无用消息从Broker 传输到消费者端。

2.4消息存储

消息中间件的一个核心实现是消息的存储，对消息存储通常有以下两个纬度的度量： 消息堆积能力和消息存储性能。RocketMQ追求消息存储的高性能，引入内存映射机制全部主题的消息顺序存储在同一个文件中。同时为了不消息无限在存储服务器中累积，引入了消息文件的过时机制与文件存储空间报警机制。

2.5 消息高可用

RocketMQ 在同步刷盘的方式下能够保证消息不丢失；在异步刷盘模式下，会丢失少许消息。

2.6 消息到达(消费)低延迟

RocketMQ 在不发生消息堆积时,以常轮询模式实现准实时消息的推送模式。

2.7 确保消息必须被消费一次

RocketMQ 经过消息消费确认机制(ACK)来确保消息至少被消费一次，单因为ACK消息有可能丢失等其余缘由，RocketMQ 没法作到消息只被消费一次，有重复消费的可能。

2.8 回溯消息

回溯消息是是指消息消费者端已经消费成功的消息，因为业务须要从新消费消息。RocketMQ支持按时间回溯消息，时间纬度可精确到毫秒，能够向前向后回溯。

2.9 消息堆积

消息中间件的主要功能是异步解耦，必须具有对前端的数据洪峰，提升后端系统的可用性，必然要求对消息中间件具有必定的消息堆积能力。RocketMQ消息存储文件并非永久存储消息在服务器端，而是提供了过时机制，默认保留3天。

2.10 定时消息

定时消息是指消息发送到Broker后，不能被消息消费者端当即消费，要到特定的时间点或者等待特定的时间后才能被消费。若是要支持任务精度的定时消息消费，必须在消息服务端对消息进行排序，势必带来很大的性能损耗，故RocketMQ不支持任意进度的定时消息，而只支持特定延迟级别。

2.11 消息重试机制

消息重试是指消息在消费时，若是发送异常，消息中间件须要支持消息的从新投递，RocketMQ支持重试机制。

3.架构设计

上面是RocketMQ的部署结构图,操做流程以下介绍：

• 一、启动Namesrv，Namesrv起来后监听端口，等待Broker、Produer、Consumer连上来，至关于一个路由控制中心。

• 二、Broker启动，跟全部的Namesrv保持长链接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储全部topic信息。注册成功后，namesrv集群中就有Topic跟Broker的映射关系。

• 三、收发消息前，先建立topic，建立topic时须要指定该topic要存储在哪些Broker上。也能够在发送消息时自动建立Topic。

• 四、Producer发送消息，启动时先跟Namesrv集群中的其中一台创建长链接，并从Namesrv中获取当前发送的Topic存在哪些Broker上，而后跟对应的Broker建长链接，直接向Broker发消息。

• 五、Consumer跟Producer相似。跟其中一台Namesrv创建长链接，获取当前订阅Topic存在哪些Broker，而后直接跟Broker创建链接通道，开始消费消息。

RocketMQ消息生产者和消费者都是一个组的概念，自然支持集群，这样能够应对大量的消息生产和消费，也是RocketMQ高吞吐量的一个标志性特征。