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

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,但是在消息负载的时候会有可能发生重复消费的可能性的,业务要做好幂等性的。其实只要没有不停机水平扩容的问题,一般正常情况是是不会重复消费的哈,但是是存在这种情况的,防止重复消费的问题还是要业务方自己去解决的。