原创文章,转载请注明出处:http://jameswxx.iteye.com/blog/2091966
我想说,真tm蛋疼,2.0和3.0架构变化挺大的,nameserver有必要吗?zookeeper不是挺好的吗?
一 nameserver
相对来说,nameserver的稳定性非常高。原因有二:
1 nameserver互相独立,彼此没有通信关系,单台nameserver挂掉,不影响其他nameserver,即使全部挂掉,也不影响业务系统使用,这点类似于dubbo的zookeeper。
2 nameserver不会有频繁的读写,所以性能开销非常小,稳定性很高。
二 broker
1 与nameserver关系
- 连接
单个broker和所有nameserver保持长连接
- 心跳
心跳间隔:每隔30秒(此时间无法更改)向所有nameserver发送心跳,心跳包含了自身的topic配置信息。
心跳超时:nameserver每隔10秒钟(此时间无法更改),扫描所有还存活的broker连接,若某个连接2分钟内(当前时间与最后更新时间差值超过2分钟,此时间无法更改)没有发送心跳数据,则断开连接。
- 断开
动作:一旦连接断开,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的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分钟,此时间无法更改)没有发送心跳数据,则关闭连接。
- 连接断开
3 负载均衡移除broker上的生产者信息
生产者时间没有关系,每个生产者向队列轮流发送消息
相关推荐
阿里RocketMQ_用户指南_V3.2.4_最新版本.pdf benchmark.pdf Metaq在JDk 7下的异常及解决方案.docx ...RocketMQ的一些特性.doc RocketMQ命令整理.doc RocketMQ群问题整理.docx RocketMQ运维指令整理.docx
RocketMQ新版本特性介绍.docx
具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。 存储选型 顺序消息 局部顺序:适用于性能要求高,以Sharding Key作为分区字段,在同一个区块中严格地按照 。 延时消息 RabbitMQ不支持延迟消息,Active...
RocketMQ 分享。目录:RocketMQ作用和特性、架构、存储模型、高可靠、事务、延时消息、消息重试、消息堆积能力
和削峰填谷的能力,同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性,是阿里巴巴双 11 使用的核心产品。 RocketMQ 的设计基于主题的发布与订阅模式,其核心功能包括消息发送、消息存储(Broker)、...
• 比较友好的分布式特性 • 同时支持 Push 与 Pull 方式消费消息 • 历经多次天猫双十一海量消息考验 目前主流的 MQ 主要是 RocketMQ、kafka、RabbitMQ,对比其主要优势有: • 支持事务型消息(消息发送和 DB 操作...
消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高 并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 版既可为分布式 应用系统提供异步解耦和削峰填谷的...积、高吞吐、可靠重试等特性。
1、消息模型 2、消息生产者(producer) 3、消息消费者(Consumer) 5、代理服务器(Broker Server) 9、 生产者组(Produc
本文档旨在描述 RocketMQ的多个关键特性实现 原理 ,并对 消息中间件 遇到的各种问题进行总结,,阐述 RocketMQ 如何解决这些问题。
本文档旨在描述 RocketMQ 的多个关键特性的实现原理,并对消息中间件遇到的各种问题进行总结,阐述 RocketMQ如何解决这些问题。文中主要引用了JMS 规范与CORBA Notification 规范,规范为我们设计系统指明了 方向,...
本文档旨在描述 RocketMQ 的多个关键特性的实现原理,幵对消息中间件遇到的各种问题迕行总结,阐述 RocketMQ 如何解决返些问题。文中主要引用了 JMS 规范不 CORBA Notification 规范,规范为我们设计系统挃明了 方吐...
本文档旨在描述 本文档旨在描述 本文档旨在描述 本文档旨在描述 本文档旨在描述 本文档旨在描述 本文档旨在描述 RocketMQ RocketMQ RocketMQRocketMQRocketMQRocketMQ的多个关键特性实现 的多个关键特性实现 的多个...
RocketMQ是一款分布式、队列模型的消息中间件,具有以下特点: 1、支持严格的消息顺序; 2、支持Topic与Queue两种模式; 3、亿级消息堆积能力; 4、比较友好的分布式特性; 5、同时支持Push与Pull方式消费消息;
whatsmars-spring spring原理、集成及新特性 whatsmars-tomcat 模拟tomcat实现 whatsmars-dbrouter 分库分表实现 whatsmars-worker 多实例任务调度 whatsmars-dubbo Dubbo demo whatsmars-mq rocketmq,activemq ...
以下是RocketMQ的一些关键特性和概述: 1.分布式:RocketMQ集群能够水平扩展,支持高并发和高容错。 2.消息队列:RocketMQ能够保证消息的顺序和高效传递。 3.持久化存储:消息存储在磁盘上,可以进行持久化。 4.高可用:...
具有以下特性: 支持发布/订阅(Pub/Sub)和点对点(P2P)消息模型 在一个队列中可靠的先进先出(FIFO)和严格的顺序传递 支持拉(pull)和推(push)两种消息模式 单一队列百万消息的堆积能力 支持多种消息协议,...
3.消息的特性 3.1.同步消息 3.2.异步消息 3.3.单向消息 3.4.延时消息 3.5.批量发送 3.6.顺序性 3.7.消息事务 3.8.过滤消息tag 4.rocketmq集群 4.1.集群分类 4.2.搭建2主2从集群 4.3.启动集群 4.4.rocketmq控制台 5....
具有以下特性: 支持发布/订阅(Pub/Sub)和点对点(P2P)消息模型 在一个队列中可靠的先进先出(FIFO)和严格的顺序传递 支持拉(pull)和推(push)两种消息模式 单一队列百万消息的堆积能力 支持多种消息...
RocketMQ是一款分布式、队列模型的消息中间件,具有以下特点: 1、支持严格的消息顺序; 2、支持Topic与Queue两种模式; 3、亿级消息堆积能力; 4、比较友好的分布式特性; 5、同时支持Push与Pull方式消费消息;