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