RocketMQ实战疑问和原理解答(实时更新)

版权声明:阅读优秀源码,宛若一场探索未知的旅行,疑惑处惊奇,优雅处旖旎; 一切都是新奇的,千回百转与大师的心灵触碰,一场跨越时空的对话,涤荡了原有的愚昧,蜕变出更好的自己。 https://blog.csdn.net/FENGQIYUNRAN/article/details/85085653

Q1:怎么解决remote toomuch exception的问题呢?

A:主要是的客户端发送的TPS太高,达到了broker的瓶颈。

Q2: broker无法写入store.log的日志报错,报异常如下:

2018-12-17 14:09:37 WARN StoreScheduledThread1 - disk space will be full soon, but delete file failed.
2018-12-17 14:09:42 WARN SendMessageThread_1 - message store is not writeable, so putMessage is forbidden 16
2018-12-17 14:09:47 INFO StoreScheduledThread1 - physic disk maybe full soon, so reclaim space, 0.9246850495308918

R:物理文件不能无限制的写入磁盘,当磁盘空间达到阈值时,不再接受消息,broker打印出日志,消息发送失败。

A:扩容 或者根据业务缩短commitlog在磁盘的保存时间。或者调大diskMaxUsedSpaceRatio = 75的默认值到90。

Q3:如果在多topic下,并发对多个partition文件写入,相当于随机io,所以性能不好,那rocketmq也会对多个consumerqueue写入,为什么就不会出现性能问题?

A:kafka与rocketmq的存储区别在于:kafka是每个topic下会对应好几个.log文件;而rocketmq则是将所有的topic消息都写在了一个commitlog里。当topic很多时,kafka下的.log文件就会很多,而commitlog数量则不会受到影响(受影响的是consumequeue,但是consumequeue文件大小很小,基本上都是在内存里,不需要访问磁盘)。

在topic很少时,kafka是顺序读,rocketmq是随机读,但是rocketmq基于os的pagecache,所以性能不会慢于顺序读。
在topic很多时,kafka文件很多,就变成了随机读,性能会下降。rocketmq依然不受影响。

kafka内存不足时会将已经缓存的数据swap到磁盘,同时再从磁盘读取新数据。增加了磁盘IO,性能就降低了。
但是rocketmq 会尽可能利用OS的磁盘IO调度算法(NOOP)以及PageCache,尽可能的减少磁盘IO。

展开阅读全文

没有更多推荐了,返回首页