原创文章,转载请注明出处: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的特性包括高可用性、高吞吐量、低延迟以及强大的消息轨迹追踪能力,使得它成为大数据、云计算领域不可或缺的组件。同时,RocketMQ社区活跃,文档完善,拥有广泛的应用案例,是企业级消息系统的理想选择。 ...
了解如何设计和实现业务逻辑,结合RocketMQ的特性,可以优化系统性能和稳定性。 9. **故障排查与优化**:学习如何处理RocketMQ常见的问题,如消息丢失、消费滞后、网络通信异常等,并了解如何通过调整参数和优化...
RocketMQConsole的特性包括: 1. **集群管理**:展示所有集群的概览,包括各个Broker的状态、CPU使用率、磁盘空间等。 2. **主题管理**:创建、删除和修改主题,查看主题的队列分布和消息堆积情况。 3. **消费者...
以下将详细讲解RocketMQ的关键特性和相关概念。 1. **消息模型**: RocketMQ的消息模型主要包括生产者、消费者和代理服务器(Broker)三部分。生产者负责创建和发送消息,消费者负责接收和处理消息,而Broker作为...
在本文中,我们将深入探讨RocketMQ Dashboard的相关知识点,包括其功能、特性、安装与使用以及它如何帮助用户更好地管理RocketMQ集群。 1. **RocketMQ Dashboard的功能**: - **监控**: 提供实时的消费者和生产者...
RocketMQ是阿里巴巴开源的一款分布式消息中间件,广泛应用于大数据、实时计算、微服务等领域,具有高可用、高并发、低延迟等特性。RocketMQ 5.1.3是该产品的一个重要版本,提供了诸多增强和优化,旨在提高性能和稳定...
"rocketmq-console-ng-2.x"代表的是RocketMQ控制台的新版本,"ng"可能指的是"Next Generation",意味着这个版本带来了更先进的特性和改进。2.0.0是这个版本的编号,通常代表着相较于之前的版本,它可能包含了大量的...
- **31-Rocketmq特性详解**:深入理解RocketMQ的各项特性,包括高可用、高吞吐量的设计实现,以及如何通过这些特性解决实际业务问题。 - **30-RocketMq性能&测试**:这部分可能涉及RocketMQ的性能测试方法、性能调优...
RocketMQ 是一个开源的分布式消息中间件,常用于构建高可用、高可靠的消息传递系统。...在实际项目中,根据业务需求选择合适的发送模式,并利用好消息过滤特性,可以极大地提升系统的稳定性和性能。
RocketMQ具有高性能、低延迟、可靠重试、分布式事务等特性,广泛应用于电商、金融、大数据、物联网等领域。 RocketMQ的由来可以追溯到阿里巴巴消息引擎的演进史。第一代为推模式,使用关系型数据库存储消息,具有低...
RocketMQ的特性主要包含发布/订阅模式、消息优先级、消息顺序、消息过滤、消息持久化、消息可靠性保证、低延迟消息处理以及消息的发送确认机制(至少一次、确保一次)。这些特性满足了不同场景下对消息中间件的需求...
**四、高级特性** 1. **发布/订阅模型**:支持点对点模型和发布/订阅模型,满足不同场景需求。 2. **顺序消息**:确保消息按照特定顺序到达消费者。 3. **事务消息**:支持分布式事务,保证消息发送与业务操作的...
RocketMQ是阿里巴巴开源的一款分布式消息中间件,广泛应用于大数据、实时计算、微服务等领域,具有高可用、高并发、低延迟等特性。本压缩包"rocketmq相关jar包.zip"包含的是RocketMQ运行所需的几个核心组件的jar包,...
2. **RocketMQ的特性**: - **高可用性**:通过主备切换和集群部署,确保服务不中断。 - **高吞吐量**:设计优化使得RocketMQ在大规模并发场景下仍能保持高吞吐。 - **低延迟**:优化的网络通信和消息调度策略...
【标题】:SpringBoot整合RocketMQ源码解析 在当今的微服务架构中,消息队列(Message Queue)已经成为解耦、异步处理以及提高系统可靠性的关键组件。本主题将深入探讨如何在SpringBoot应用中整合Apache RocketMQ,...
**RocketMQ的核心特性** 1. **高吞吐量**:RocketMQ设计之初就考虑了大规模数据的处理,能够在高并发场景下保持稳定的性能。 2. **低延迟**:RocketMQ提供多种消息模型,如发布/订阅模式和点对点模式,满足不同场景...
RocketMQ具有高可用、高并发、低延迟、稳定可靠等特性,支持发布/订阅模式和点对点模式的消息传递,适用于交易系统、物联网应用、大数据处理等多种场景。 在"rocketmq-all-5.1.3-bin-release"这个压缩包中,包含了...
RocketMQ 是阿里巴巴开源的一款分布式消息中间件,它具有高吞吐量、低延迟、高可用性和可扩展性等特性,广泛应用于互联网和金融行业的实时交易、大数据处理等领域。Spring 框架是Java开发中最常用的框架之一,用于...
在这个更新中,RocketMQ Console增加了两个重要的安全特性:ACL(Access Control List)鉴权和控制台登录验证。 1. ACL鉴权: ACL,即访问控制列表,是一种常见的权限管理系统,用于限制用户或角色对资源的访问。...