RocketMQ的一些特性

一 nameserver

相对来讲，nameserver的稳定性很是高。缘由有二：

1 nameserver互相独立，彼此没有通讯关系，单台nameserver挂掉，不影响其余nameserver，即便所有挂掉，也不影响业务系统使用，这点相似于dubbo的zookeeper。

2 nameserver不会有频繁的读写，因此性能开销很是小，稳定性很高。

 

二 broker

1 与nameserver关系

• 链接

     单个broker和全部nameserver保持长链接

• 心跳

     心跳间隔：每隔30秒（ 此时间没法更改）向全部nameserver发送心跳，心跳包含了自身的topic配置信息。

     心跳超时：nameserver每隔10秒钟（ 此时间没法更改），扫描全部还存活的broker链接，若某个链接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间没法更改）没有发送心跳数据，则断开链接。

• 断开

     时机：broker挂掉；心跳超时致使nameserver主动关闭链接

     动做：一旦链接断开，nameserver会当即感知，更新topc与队列的对应关系，但不会通知生产者和消费者

 

2 负载均衡

• 一个topic分布在多个broker上，一个broker能够配置多个topic，它们是多对多的关系。
• 若是某个topic消息量很大，应该给它多配置几个队列，而且尽可能多分布在不一样broker上，减轻某个broker的压力。
• topic消息量都比较均匀的状况下，若是某个broker上的队列越多，则该broker压力越大。

 

3 可用性

   因为消息分布在各个broker上，一旦某个broker宕机，则该broker上的消息读写都会受到影响。因此rocketmq提供了 master/slave的结构，salve定时从master同步数据，若是master宕机，则slave提供消费服务，可是不能写入消息，此过程对 应用透明，由rocketmq内部解决。

这里有两个关键点：

• 一旦某个broker master宕机，生产者和消费者多久才能发现？受限于rocketmq的网络链接机制，默认状况下，最多须要30秒，但这个时间可由应用设定参数来缩短期。这个时间段内，发往该broker的消息都是失败的，并且该broker的消息没法消费，由于此时消费者不知道该broker已经挂掉。

• 消费者获得master宕机通知后，转向slave消费，可是slave不能保证master的消息100%都同步过来了，所以会有少许的消息丢失。可是消息最终不会丢的，一旦master恢复，未同步过去的消息会被消费掉。

 

4 可靠性

• 全部发往broker的消息，有同步刷盘和异步刷盘机制，总的来讲，可靠性很是高
• 同步刷盘时，消息写入物理文件才会返回成功，所以很是可靠
• 异步刷盘时，只有机器宕机，才会产生消息丢失，broker挂掉可能会发生，可是机器宕机崩溃是不多发生的，除非忽然断电

5 消息清理

• 扫描间隔

     默认10秒，由broker配置参数cleanResourceInterval决定

• 空间阈值

     物理文件不能无限制的一直存储在磁盘，当磁盘空间达到阈值时，再也不接受消息，broker打印出日志，消息发送失败，阈值为固定值85%

• 清理时机

     默认天天凌晨4点，由broker配置参数deleteWhen决定；或者磁盘空间达到阈值

• 文件保留时长

     默认72小时，由broker配置参数fileReservedTime决定

 

 

6 读写性能

• 文件内存映射方式操做文件，避免read/write系统调用和实时文件读写，性能很是高
• 永远一个文件在写，其余文件在读
• 顺序写，随机读
• 利用linux的sendfile机制，将消息内容直接输出到sokect管道，避免系统调用

7 系统特性

• 大内存，内存越大性能越高，不然系统swap会成为性能瓶颈
• IO密集
• cpu load高，使用率低，由于cpu占用后，大部分时间在IO WAIT
• 磁盘可靠性要求高，为了兼顾安全和性能，采用RAID10阵列
• 磁盘读取速度要求快，要求高转速大容量磁盘

 

三 消费者

1 与nameserver关系

• 链接

     单个消费者和一台nameserver保持长链接，定时查询topic配置信息，若是该nameserver挂掉，消费者会自动链接下一个nameserver，直到有可用链接为止，并能自动重连。

• 心跳

与nameserver没有心跳

• 轮询时间

默认状况下，消费者每隔30秒从nameserver获取全部topic的最新队列状况，这意味着某个broker若是宕机，客户端最多要30秒才能感知。该时间由 DefaultMQPushConsumer的pollNameServerInteval参数决定，可手动配置。

 

2 与broker关系

• 链接

单个消费者和该消费者关联的全部broker保持长链接。

• 心跳

默认状况下，消费者每隔30秒向全部broker发送心跳，该时间由DefaultMQPushConsumer的heartbeatBrokerInterval参数决定，可手动配置。broker每隔10秒钟（此时间没法更改），扫描全部还存活的链接，若某个链接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间没法更改）没有发送心跳数据，则关闭链接，并向该消费者分组的全部消费者发出通知，分组内消费者从新分配队列继续消费

• 断开

时机：消费者挂掉；心跳超时致使broker主动关闭链接

动做：一旦链接断开，broker会当即感知到，并向该消费者分组的全部消费者发出通知，分组内消费者从新分配队列继续消费

 

3 负载均衡

集群消费模式下，一个消费者集群多台机器共同消费一个topic的多个队列，一个队列只会被一个消费者消费。若是某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。

 

4 消费机制

• 本地队列

        消费者不间断的从broker拉取消息，消息拉取到本地队列，而后本地消费线程消费本地消息队列，只是一个异步过程，拉取线程不会等待本地消费线程，这种 模式实时性很是高。对消费者对本地队列有一个保护，所以本地消息队列不能无限大，不然可能会占用大量内存，本地队列大小由DefaultMQPushConsumer的pullThresholdForQueue属性控制，默认1000，可手动设置。

• 轮询间隔

     消息拉取线程每隔多久拉取一次？间隔时间由DefaultMQPushConsumer的pullInterval属性控制，默认为0，可手动设置。

• 消息消费数量

     监听器每次接受本地队列的消息是多少条？这个参数由DefaultMQPushConsumer的consumeMessageBatchMaxSize属性控制，默认为1，可手动设置。

 

5 消费进度存储

     每隔一段时间将各个队列的消费进度存储到对应的broker上，该时间由DefaultMQPushConsumer的persistConsumerOffsetInterval属性控制，默认为5秒，可手动设置。

 

6 若是一个topic在某broker上有3个队列，一个消费者消费这3个队列，那么该消费者和这个broker有几个链接？

     一个链接，消费单位与队列相关，消费链接只跟broker相关，事实上，消费者将全部队列的消息拉取任务放到本地的队列，挨个拉取，拉取完毕后，又将拉取任务放到队尾，而后执行下一个拉取任务

 

 

四 生产者

1 与nameserver关系

• 链接

     单个生产者者和一台nameserver保持长链接，定时查询topic配置信息，若是该nameserver挂掉，生产者会自动链接下一个nameserver，直到有可用链接为止，并能自动重连。

• 轮询时间

默认状况下，生产者每隔30秒从nameserver获取全部topic的最新队列状况，这意味着某个broker若是宕机，生产者最多要30秒才能感知，在此期间，发往该broker的消息发送失败。该时间由DefaultMQProducer的pollNameServerInteval参数决定，可手动配置。

• 心跳

与nameserver没有心跳

 

2 与broker关系

• 链接

单个生产者和该生产者关联的全部broker保持长链接。

• 心跳

默认状况下，生产者每隔30秒向全部broker发送心跳，该时间由DefaultMQProducer的heartbeatBrokerInterval参数决定，可手动配置。broker每隔10秒钟（此时间没法更改），扫描全部还存活的链接，若某个链接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间没法更改）没有发送心跳数据，则关闭链接。

• 链接断开

移除broker上的生产者信息

 

3 负载均衡

     生产者时间没有关系，每一个生产者向队列轮流发送消息

 

引用连接： http://jameswxx.iteye.com/blog/2091966