不客气. 顺便说一下, 下次有疑问, 把邮件直接发送到users@rocketmq.apache.org <mailto:users@rocketmq.apache.org> 这样有更多的同学\更及时的回复你.
> 在 2018年6月4日，下午11:06，龚皓 <369897...@qq.com> 写道： > > 非常感谢您的回复，有一种豁然开朗的感觉，非常感谢 > > ---原始邮件--- > 发件人: "Zhanhui Li"<lizhan...@gmail.com> > 发送时间: 2018年6月4日(星期一) 晚上8:46 > 收件人: "users"<users@rocketmq.apache.org>;"龚皓"<369897...@qq.com>; > 抄送: "lizhanhui"<lizhan...@apache.org>; > 主题: Re: Hi，您好，我想请教您几个rocketmq的问题，不知道您方便么？ > >> 龚皓你好, > > > 如果有大量的consume queue, 对系统确实还是有一些影响的. 下面解释下为什么这个影响可控. > > 1. 每一条消息, 对应的consume queue entry大小只有20字节. 也就是说, 一个queue里面, 发送200多条消息, > 才需要一次IO去存储. > 2. 由于consume queue完全可以从commit log中构造出来, consume queue的刷盘策略, 可以配置的更松弛一些, > 比如每隔T刷盘一次. 这样可以进一步减少随机IO的量. 当然, 这里涉及内存和IO的一个平衡. > 3. 实际生产上, 经常会把consume queue和commit log分配到不同的磁盘. > > 李战辉 > > >> 在 2018年6月3日，下午7:52，龚皓 <369897...@qq.com <mailto:369897...@qq.com>> 写道： >> >> 您好! >> 我们是一家中型互联网公司的，我对rocketmq支持海量topic的功能特别感兴趣，也特别疑惑。我看到就是说 >> rocketmq相较于kafka，分离了consume queue文件和commit log文件。用户读写的时候都是顺序读写queue文件的， >> 但这个地方我就非常有点搞不懂。虽然是顺序读写，但是如果topic数量上万，上10w，还是会产生大量的磁盘随机读写（用来打开对应文件）， >> 请问您在设计这个地方的是时候具体是使用了什么方式，或者需要什么特别的机器适配这种业务场景，或者还是什么其他地方我理解错了 >> 非常打扰，万分感谢 >> >> 环球易购 >> >> 龚皓 >
