此篇博文主要会描述使用过程中遇到的各种问题以及从官网上收集到的需要注意的重点,后期会持续更新。
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仍然可以拉消息
转载于:https://blog.51cto.com/binbinwudi8688/1673377