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

307 阅读4分钟

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的部署结构图,操作流程如下介绍:

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

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

  • 3、收发消息前,先创建topic,创建topic时需要指定该topic要存储在哪些Broker上。也可以在发送消息时自动创建Topic。

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

  • 5、Consumer跟Producer类似。跟其中一台Namesrv建立长连接,获取当前订阅Topic存在哪些Broker,然后直接跟Broker建立连接通道,开始消费消息。

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