Rocketmq整体分析

时间:2021-10-20 13:36:18

之前本人在实际的生产环境中,使用过activemq和rabbitmq消息队列,在使用过程中出现一些难以解决的问题,本文通过产品选型、网络架构和核心特性分析了rocketmq的优势和特性。

产品选型

我们在进行中间件选型时,一般都是通过下面几点来进行产品选型的:

1.性能

2.功能支持程度

3.开发语言(团队中是否有成员熟悉此中间件的开发语言,市场上此种语言的开发人员是否好招)

4.有多少公司已经在生产环境上实际使用过,使用的效果如何

5.社区的支持力度如何

6.中间件的学习程度是否简单、文档是否详尽

7.稳定性

8.集群功能是否完备

...

如果从以上8点来选型一个消息队列,作为一名熟悉java的程序员,当遇到重新选择消息队列的场景时,我会毫不犹豫的选型rocketmq,rocketmq除了在第5点上表现略差(文档少,学习成本高)以及监控管理功能不友好外,从其它方面来说,它真的是一款非常优秀的消息队列中间件。

网络架构

Rocketmq整体分析

(图片来源于官方文档)

rocketmq的主要部分是由4种集群构成的:namesrv集群、broker集群、producer集群和consumer集群。

namesrv集群:也就是注册中心,rocketmq在注册中心这块没有使用第三方的中间件,而是自己写的代码来实现的,代码行数才1000行,producer、broker和consumer在启动时都需要向namesrv进行注册,namesrv服务之间不通讯。

broker集群:broker提供关于消息的管理、存储、分发等功能,是消息队列的核心组件。rocket关于broker的集群提供了主要两种方案,一种是主从同步方案,消息同时写到master和slave服务器视为消息发送成功;另一种是异步方案,slave的异步服务负责读取master的数据,本人在选择时更倾向于异步方案。

producer集群:消息的生产者,每个producer都需要属于一个group,producer的group概念除了在事务消息时起到一些作用,但是其它时候,更多的还只是一个虚拟的概念。

consumer集群:消息的消费者,有两个主要的consumer:DefaultMQPullConsumer和DefaultMQPushConsumer,深入代码后可以发现,rocket的consumer都是采用的pull模式来处理消息的。在集群消息的配置下,集群内各个服务平均分配消息,当其中一台consumer宕机,分配给它的消息会继续分配给其它的consumer。

核心特性

1.读队列数量和写队列数量可以不一致:当我们使用updateTopic命令创建topic时,会发现新建的topic下会有默认的8个写对列和8个读对列(依赖于配置),并且读队列的数量和写队列的数量还可以不一致,这是为什么呢?难道在底层读写队列是在物理上分离的吗?抱着这个问题,我分析了相关的源代码,发现底层代码对于读写队列指的都是同一个队列,其中写队列的数量是针对的producer,读队列的数量针对的是consumer:

a.假设写队列有8个、读队列有4个,那么producer产生的消息会按轮训的方式写入到8个队列中,但是consumer却只能消费前4个队列,只有把读队列重新设置为8后,consumer可以继续消费后4个队列的历史消息;

b.假设写队列有4个、读队列有8个,那么producer产生的消息会按轮训的方式写入到4个队列中,但是consumer却能消费8个队列,只是后4个队列没有消息可以消费罢了。

2.存储为文件存储方式,支持同步落盘和异步刷盘两种方式,我倾向于选择异步刷盘的方式,毕竟broker挂掉的概率比较小,大部分的业务场景下在极端情况下丢失及其少量消息是可以忍受的;

3.支持消息回溯,支持定期删除历史消息;

4.集群方案比activemq要优秀很多,支持多主多从方案,例如在2主2从异步架构下,a,b为master,as,bs为slaver,当a机宕机后,producer会将消息全部发往b机,consumer会消费as,b和bs上的消息,理论上只会丢失毫秒级别的消息,不会影响业务的正常使用。可以说rocketmq的集群方案完爆activemq的集群方案,很多时候,我们对于异步队列的性能要求不高,但是集群的可用性要求一定是很高的。下面是activemq的三种集群方案:

a.磁盘阵列类,成本较高,也是一种通用的方案;

b.利用jdbc来实现统一存储消息,不但性能成问题,而且也只是把问题丢给了数据库罢了,没有解决集群的单机问题;

c.利用zookeeper的注册中心的选主功能,在各个服务之间同步数据,在实际的使用过程中发现主机自动漂移,同步数据不完全造成的数据错乱且服务启动不了,反而不如单机来的稳定;

5.队列数量单机支持10000个以上;

6.consumer支持集群功能,可以平均消费消息,当有一台consumer宕机后,其它consumer继续均分;

7.consumer是靠pull的方式来消费消息的,性能不低于push的方式,这也是broker的并行能力强的一个原因,将主动权下放给了consumer,降低了broker的运算量和线程切换成本;

8.支持顺序消息,可以在发送消息时,利用selector机制的hash方式取模来实现消息落到哪个broker的哪个queue上,当某个broker宕机后,由于取模值也发生变化,会自动切换队列;

9.producer发送消息时支持同步返回、异步返回和oneway三种方式;

10.broker保证每条消息至少投递到consumer一次,因此consumer的业务需要支持幂等;

11.消息堆积能力惊人,消息队列的一个作用便是防止洪峰直接冲垮后端业务;

12.支持按照消息id和消息key来查询消息,本人很喜欢按照key来查询消息这个功能,例如在下单业务中,可以使用订单id作为key,便于分析异常订单在系统中的处理过程;

13.支持消息过滤;

...