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。