RocketMQ-05问题及故障点

此篇博文主要会描述使用过程中遇到的各种问题以及从官网上收集到的需要注意的重点,后期会持续更新。

1)RocketMQ 故障之 - 在压力测试下无法启动

在压力之下,MQ会堆积,如果堆积太多,会导致MQ同步offset的问题,需要清空:

1.停止rocketmq:kill -9 进程号

2.删除/root下的 /logs/rocketmqlogs:大量日志

3.删除/root/store:这里存储的MQ的topic等信息

4.[optional]清空MQ里显示的topic

sh mqadmin topicList -n 192.168.100.34:9876

sh mqadmin deleteTopic -c HOSTNAME -n 192.168.100.34:9876 -t orderTopic

*然后重启rocketmq再尝试第四步看看是否清除干净

PS:
    1. 先;如果没有都清楚,rocketmq不知道从哪里还会把所有积攒的再加载回来,导致还是无法启动rocketmq
    2. deleteTopic不是必须的,但是删除的时候一般都需要制定 -c,可以用hostname试试

2)RocketMQ Server关闭时,数据安全性如何保证?

PS:这里我为什么单独提取出来放在这里,在我们启动关闭程序时,一定要注意kill这玩意。

A.正常关闭,一般通过人工调用kill -15 pid形式关闭,Server内部会捕获Sigterm信号,并进行处理,将内存数据全部刷盘。

B.异步刷盘情况下,异常关闭(重启时,必须要进行纠错)

a) Kill -9 形式关闭,由于程序无法捕获-9 信号,会被非法关闭。

此时向Commit Log写消息可能会只写入半个消息,Comsume Queue同样也存在这种情况,都是最后一个消息无法保证正常写入。

但是之前写入完整的消息虽然未刷盘,也可以保证不丢失,数据只要进入Pagecache,即使程序crash,仍在内存中可以通过sync命令刷盘(系统内置命令)

b)OS crash或机器掉电

此种情况,只要未刷盘的数据将全部丢失

根据性能压测结果,实际在内存未刷盘数据大概在几十k的样子,也就是说最糟糕的情况会有几址K的消息丢失

c) 同步刷盘情况下,异常关闭(重启时,必须要进行纠错)

B中涉及的两种异常情况,都不会丢消息,但是可能存在如下情况

当消息写入到pagecache,刷盘刷到一半时,此时还未向Producer返回成功,但是机器掉电或者OS crash,这个半个消息是脏数据,重启时需要纠错。另外Producer也会收到超时异常,由用户决定是否要重试。

综合,同步刷盘情况下,异常关闭不会丢消息。

3)RocketMQ Server重启时,如何Load数据?

A.上次正常退出后重启

正常退出指的是,所有内存数据都已经正常刷盘,Commit Log与Consume Queue对应关闭一致,恢复时各自独立恢复到内存即可。

B.上次异常退出后重启

异常退出指的是,Commit Log与Consume Queue可能数据不一致,有可能Commit Log比Consume Queue数据多,也有可能Consume Queue 比 Commit Log数据多,这里以Commit Log数据为主,从Commit Log上次刷盘位置开始扫描Commit Log,,将消息重新发至Consume Queue。

如果此文件丢失,则会对Commit Log进行全盘扫描恢复,这种情况会耗时较长。

4)RocketMQ 是否需要流控?

A.对于发送消息,接受消息不需要流控

因为性能测试中,千兆网卡上下行同时压满(流量都在100M以上),系统指标仍然正常。但是同时需要监控磁盘空间剩余量,因为在高TPS场景下,磁盘很快就会被写满。

B.Server内部将消息消息位置信息派发至各个Consume Queue需要流控

在1W队列下一般不需要流控,但是超过1W个队列,则是对队列的写性能会下降,此时前端请求过来,消息位置信息会在java堆中堆积,默认阀值是40万,超过则开始流控,对前端请求做1毫秒sleep

5)RocketMQ如何金判断是正常退出还是异常退出?

RocketMQ启动时,都会在指写目录传创建一个文件"Abort",如果正常退出,则将文件删除,如果异常退同,则没有机会删除文件,所以异常退出,则没有机会删除文件,所以在RocketMQ重启时,只要发现这个文件存在就认为上次是异常退出,需要校验数据,如果文件不存在,则认为上次是正常退出,数据都OK。

6)RocketMQ有哪些自我保护措施?

A .磁盘空间使用超过90%,Server自动停止对外写服务,也就是发送方发消息会被拒绝。Consumer仍然可以拉消息。

B.消息向Consume Queue写入失败时,尝试重试3次,如果仍然失败,则认为IO设备发生重大错误,停止对外写服务。Consumer仍然可以拉消息

时间: 2024-08-02 08:29:46

RocketMQ-05问题及故障点的相关文章

《RocketMQ 安装和使用》

安装Maven http://maven.apache.org/download.cgi (apache-maven-3.3.3-bin.zip) 安装步骤:<Maven的安装.配置及使用入门> http://www.cnblogs.com/dcba1112/archive/2011/05/01/2033805.html Path环境变量,当我们在cmd中输入命令时,Windows首先会在当前目录中寻找可执行文件或脚本,如果没有找到,Windows会接着遍历环境变量Path中定义的路径.由于我

RocketMQ在windows上安装和开发使用

概述RocketMQ是alibaba公司开源的一个纯java的开源消息中间件. 开发测试环境搭建1.   安装&启动进入到RocketMQ下载包解压的路径下D:\machine\RocketMQ-3.0.8\RocketMQ-3.0.8>接下来安装执行下边的命令或者执行install.bat(在这个bat文件中的命令如下)对maven熟悉的一眼就知道是执行clean package install assembly等操作.mvn -Dmaven.test.skip=true clean pa

RabbitMQ,Apache的ActiveMQ,阿里RocketMQ,Kafka,ZeroMQ,MetaMQ,Redis也可实现消息队列,RabbitMQ的应用场景以及基本原理介绍,RabbitMQ基础知识详解,RabbitMQ布曙

消息队列及常见消息队列介绍 2017-10-10 09:35操作系统/客户端/人脸识别 一.消息队列(MQ)概述 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为: 当不需要立即获得结果,但是并发量又需要进行控制的时候,差不多就是需要使用消息队列的时候. 消息队列主要解决了应用耦合.异步处理.流量削锋等问题. 当前使用较多的消息队列有RabbitMQ.RocketMQ.ActiveMQ.Kafka.ZeroMQ.MetaMq等,而部分数据库如Re

RocketMQ简介及实践

What is RocketMQ Apache RocketMQ是一个分布式消息传递和流平台,具有低延迟,高性能和可靠性,万亿级容量和灵活的可扩展性. 它由四部分组成:NamerServer,Broker,Produer和Customer. 它们中的每一个都可以水平扩展而没有单一的故障点. 如下面的截图所示. NameServer Cluster NameServers提供轻量级服务发现和路由. 每个NameServer记录完整的路由信息,提供相应的读写服务,并支持快速存储扩展. NameSer

RocketMQ消费批拉超过32不生效

由于一些原因,我需要RocketMQ消费的时候,一批拉400条,一批处理400条.设置如下: 为了简单验证是否正确,消费如下: 直接通过打印msgs.size()观察情况即可. 现象 实验的topic里面的消息数量很多很多,但是启动消费端,消费端的日志如下: 奇怪啦,明明已经进行了修改 为什么还是每次只能消费32条呢? 调试RocketMQ源码 通过跟踪consumer代码: 这里的确已经设置为400了,那么我们需要跟踪到broker服务端进行查看了. broker接受到的也是400,我们只有继

【RocketMQ】同一个项目中,同一个topic,可以通过不同的tag来订阅消息吗?

一.问题答案 是不可以的 而且后注册的会替换前注册的,MqConsumer2会替换MqConsumer,并且只结束tag-2的消息 /** * @date 2019/05/28 */ @Component @Slf4j public class MqConsumer implements MessageConsumer { @Override @Transactional(rollbackFor = Throwable.class, propagation = Propagation.REQUI

RocketMQ事务消息学习及刨坑过程

一.背景 MQ组件是系统架构里必不可少的一门利器,设计层面可以降低系统耦合度,高并发场景又可以起到削峰填谷的作用,从单体应用到集群部署方案,再到现在的微服务架构,MQ凭借其优秀的性能和高可靠性,得到了广泛的认可. 随着数据量增多,系统压力变大,开始出现这种现象:数据库已经更新了,但消息没发出来,或者消息先发了,但后来数据库更新失败了,结果研发童鞋各种数据修复,这种生产问题出现的概率不大,但让人很郁闷.这个其实就是数据库事务与MQ消息的一致性问题,简单来讲,数据库的事务跟普通MQ消息发送无法直接绑

[转帖]Rocketmq原理&amp;最佳实践

Rocketmq原理&最佳实践 https://www.jianshu.com/p/2838890f3284 彦帧关注 142018.08.05 15:48:44字数 3,451阅读 174,582 一. MQ背景&选型 消息队列作为高并发系统的核心组件之一,能够帮助业务系统解构提升开发效率和系统稳定性.主要具有以下优势: 削峰填谷(主要解决瞬时写压力大于应用服务能力导致消息丢失.系统奔溃等问题) 系统解耦(解决不同重要程度.不同能力级别系统之间依赖导致一死全死) 提升性能(当存在一对多调

Kafka,RocketMQ,RabbitMQ部署与使用体验

前言 近期在研究各种消息队列方案,为了有一个直观的使用体验,我把Kafka,RocketMQ,RabbitMQ各自部署了一遍,并使用了最基本的生产与消费消息功能.在部署过程中也遇到一些问题,特此记录.本文只适用于没有使用过消息队列,还停留在安装部署阶段的新手用户,要了解一个软件,最好的开始方法是开始使用他,这样才会有一个直观的印象.本篇文章的作用也在于此,至于需要了解更深入的架构与细节,则需要查询其他的文档资料,这也不是本文的目的.我这里使用的操作系统是Centos 6.x,硬件配置一般即可.

分布式开放消息系统(RocketMQ)的原理与实践

分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 消息的顺序问题 消息的重复问题 RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性?其实现原理是怎样的? 关键特性以及其实现原理 一.顺序消息 消息有序指的是可以按照消息的发送顺序来消费.例如:一笔订单产生了 3 条消息,分别是订单创建.订单付款.订单完成.消费时,要按照顺序依次消费才有意