RocketMQ系列之架构浅谈

前言

上节我们介绍了一个RMQ的简单入门级别的demo,我们知道了生产者生产消息到MQ,然后消费者订阅消费的过程,但是那只是很简单的讲解了一下,还有很多细节我们没有去细说,今天开始我们将一个个深入的讲解下,首先今天我们先讲讲RMQ的架构设计和结构。

RMQ的架构设计

下面我从GitHub上截取了一张RMQ的源码结构图,图中我框框出来的9大模块,基本就构成了整个RMQ的内部结构

上面9大模块的依赖层次主要如下,依赖越强的越处于底层:

下面介绍下最上层的4个模块,这4个模块中工具命令行就不讲了,用于终端操作RMQ的命令时使用的,另外3个模块在RMQ上都有相对应的服务可以启动并使用:

rocketmq-nameserver:名称服务,可以理解成在RMQ中就是一个轻量级的ZK,但是它比zk的性能要好,可靠性更强,nameserver主要有下面2个作用:

扮演着nameNode的角色,记录运行时消息相关的meta信息,以及broker和filtersrv运行信息,是可以集群部署的;

主要用于节点之间相互进行心跳检测,数据通信,集群高可用、一致性、容错性等核心模块;

rocketmq-broker:数据存储的核心,这里真正存储的MQ服务器,我们的消息存储、接收、拉取、推送操作都是在broker上进行的;

rocketmq-filtersrv:消息过滤,RMQ使用一个独立的模块对数据进行过滤,主要是通过自己编写一个过滤规则的代码,编译之后,放到filtersrv模块下,然后启动filter服务之后,消费者进行消费时,指定订阅的主题topic的时候就可指定一个过滤类,加载这个过滤类执行这个过滤规则,但是这样做其实是不太安全的,相当于我们把我们的业务逻辑直接暴露在了RMQ服务器上;

RocketMQ基本设计

消费模式

RocketMQ不遵循JMS规范,有一套自定义的机制,它不存在点对点和发布订阅模式的区别,简单的说,RMQ都是使用订阅主题的方式去发送和接收消息的,支持的消费模型有下面2种:

集群模式:消费端设置消费模式为MessageModel.CLUSTERING,这种方式就可以达到水平扩展负载均衡消费消息

广播模式:消费端设置消费模式MessageModel.BROADCASTING这种模式下,就是相当于生产者端发送消息到RMQ,多个消费者端可以同时获得消息消息,顾名思义广播模式

GroupName

在RMQ中有一个很重要的概念,就是GroupName,无论生产者producer还是消费者consumer都必须指定一个GroupName,这个组主要用来标识生产者的唯一性,一类producer的集合,相同组下的producer通常发送同一类消息,且发送逻辑一致,消费者端也一样,消费者端在消费消息时,会平均分配给同一个组下的多个consumer消费,通过GroupName实现消费者天然的负载均衡消费。

Topic主题

每个主题表示一个逻辑上存储的概念,而在其MQ上,会有着与之对应的多个Queue队列,这个是物理存储的概念

消息存储

RocketMQ的消息存储主要由consumer queue与commit log协作完成的

consumer queue是消息的逻辑队列,用来指定消息在物理文件commit log上的位置,相当于字典的目录一样;

commit log是消息存放的物理文件,每台broker上的commitlog被本机所有的queue共享;

消息存储结构如下所示:

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180424G1PFCY00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券