Rocketmq整体分析

悠悠 2022-06-16 14:49 169阅读 0赞

#    之前本人在实际的生产环境中，使用过activemq和rabbitmq消息队列，在使用过程中出现一些难以解决的问题，本文通过产品选型、网络架构和核心特性分析了rocketmq的优势和特性。     产品选型      我们在进行中间件选型时，一般都是通过下面几点来进行产品选型的：      1.性能      2.功能支持程度      3.开发语言(团队中是否有成员熟悉此中间件的开发语言，市场上此种语言的开发人员是否好招)      4.有多少公司已经在生产环境上实际使用过，使用的效果如何      5.社区的支持力度如何      6.中间件的学习程度是否简单、文档是否详尽      7.稳定性      8.集群功能是否完备      ...      如果从以上8点来选型一个消息队列，作为一名熟悉java的程序员，当遇到重新选择消息队列的场景时，我会毫不犹豫的选型rocketmq，rocketmq除了在第5点上表现略差(文档少，学习成本高)以及监控管理功能不友好外，从其它方面来说，它真的是一款非常优秀的消息队列中间件。     网络架构     ![1003073-20161128141755412-613910223.png][]   (图片来源于官方文档)      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.支持消息过滤；      ... #

[1003073-20161128141755412-613910223.png]: /images/20220616/6789d1344bb94a6481e9016246b43fdb.png