Q1：怎么解决remote too much 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。
Q4:中通使用rocketmq的消息 落盘方式，以及主从同步方式，是sync还是async呢？还是说根据场景不同的集群选择 不同的组合？
A: 中通目前采用异步刷盘方式，不保证消息不丢失，由应用去重新发送；对于特殊业务要起高的集群，会采用同步刷盘的方式，保证消息不丢失；目前集群仍采用master-slave的架构，还未采用dledger集群架构；
其实如果rocketMQ真的实现exactly once，在用的时候，肯定也会把幂等逻辑加上去。设计方案的时候，一定要认为中间件是可能出问题的，而事实上，每个软件都可能出问题。
不能要求 rockemq 性能极高，又不允许数据丢失的可能，这是权衡，中间件，业务完美配合，协作。RocketMQ 创造一位大佬说的一句话，例如RocketMQ如何实现不会重复消费这个难题，他的解决方法是不解决。
Q5:如果直接使用公网的rocketmq，怎么保证数据安全?
A: rocketmq是支持ssl的
Q6:如果在正常消费的过程中，增加或减少了topic队列数，还能够正常消费吗？会出现问题？
A：在消费过程中修改broker队列会导致消费重新进行负载，进而可能会导致有部分消息重复消费。
Q7:RocketMQ会不会出现，同一条消息并发到相同的节点进行消费，还是说可能会有两条一样的消息，但是先后消费？
A：一般不会出现同一条消息并发到相同节点进行消费，无论是集群模式还是广播模式。同一时间只会发送到一个queue,但是在消息负载的时候会有可能发生重复消费的可能性的,业务要做好幂等性的。其实只要没有不停机水平扩容的问题,一般正常情况是是不会重复消费的哈,但是是存在这种情况的,防止重复消费的问题还是要业务方自己去解决的。
Q8: RocketMQ从哪个版本开始支持了自动选择Master,即支持DLedger 集群模式？
A：从4.4.0版本开始。
Q9：RocketMQ支持queue粒度数据迁移么？ 从一组broker任意迁移另外一组，比如broker坏了的情况下。
A：目前不支持，因为数据都混在 一个 commitlog 文件中，自己可以通过改造实现。
