rocketmq 学习记录-2

产品选型

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

    1.性能

    2.功能支持程度

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

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

    5.社区的支持力度如何

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

    7.稳定性

    8.集群功能是否完备

    ...

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

网络架构

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。负责消费消息,一般是后台系统负责异步消费。

 

  • Pull Consumer,Consumer 的一种,应用通常主动调用 Consumer 的拉消息方法从 Broker 拉消息,主动权由应用控制。
  • Push Consumer,Consumer 的一种,应用通常向 Consumer 对象注册一个 Listener 接口,一旦收到消息,Consumer 对象立 刻回调 Listener 接口方法。

 

  • Producer Group,一类 Producer 的集合名称,这类 Producer 通常发送一类消息,且发送逻辑一致。
  • Consumer Group,一类 Consumer 的集合名称,这类 Consumer 通常消费一类消息,且消费逻辑一致。
  • Broker,消息中转角色,负责存储消息,转发消息,一般也称为 Server。在 JMS 规范中称为 Provider。

 

 

 核心特性

   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.支持消息过滤;

 

关于高可用

RocketMQ 实现高可用的方式有多种,《RocketMQ 用户指南》文档中提到的有:多主模式、多主多从异步复制模式、多主多从同步复制模式。多主模式下,性能较好,但是在 Broker 宕机的时候,该 Broker 上未消费的交易不可消费;多主多从异步复制模式,与 Kafka 的副本模式比较类似,主 Broker 宕机后,会自动切换到从 Broker,消息的消费不会出现间断;多主多从同步复制模式更进一步,采用同步刷盘的方式,避免了主 Broker 宕机带来的消息丢失,但是,目前不支持自动切换。

虽然 RocketMQ 提供了多种高可用方式,但是目前能生产使用的就只有多主多从异步复制模式,即使在这个模式上,其实现也比 Kafka 要差。因为 RocketMQ 的机制中,主从关系是人为指定的,主 Broker 上承担所有的消息派发,而 Kafka 的主从关系是通过选举的方式选出来的,每个分区的主节点都是不一样的,可以从不同的节点派发消息。Kafka 的模式是分散模式,有利于负载均衡,而且当一个 Broker 宕机的时候,只影响部分 Topic,而 RocketMQ 一旦主 Broker 宕机,会影响所有的 Topic。另外,Kafka 可以支持 Broker 间同步复制(通过设置 Broker 的 acks 参数),这样比的话,RocketMQ 就差太多了。

关于 RocketMQ 的介绍,网上的文章不算太多,也比较杂,《分布式开放消息系统(RocketMQ)的原理与实践》5 6 7这篇原理介绍的不错,推荐。

文档都是从网上转来的,在此只作为笔记使用。不做他用

文章转自:http://www.cnblogs.com/mantu/p/6108645.html

http://valleylord.github.io/post/201607-mq-rocketmq/

 http://blog.csdn.net/lovesomnus/article/details/51776942

http://www.jianshu.com/p/453c6e7ff81c

http://www.tuicool.com/articles/f2aaUnV

posted @ 2017-05-24 14:11  BigBao的博客  阅读(1307)  评论(0编辑  收藏  举报