RocketMQ消息发送常见错误与解决方案

RocketMQ会每一分钟打印前一分钟内消息发送的耗时情况分布，我们从这里就能窥探RocketMQ消息写入是否存在明细的性能瓶颈，其区间如下：

• [<=0ms] 小于0ms，即微妙级别的。

• [0~10ms] 小于10ms的个数。

• [10~50ms]　大于10ms小

• 于50ms的个数

其他区间显示，绝大多数会落在微妙级别完成，按照笔者的经验如果100-200ms及以上的区间超过20个后，说明Broker确实存在一定的瓶颈，如果只是少数几个，说明这个是内存或pagecache的抖动，问题不大。

通常情况下超时通常与Broker端的处理能力关系不大，还有另外一个佐证，在RocketMQ broker中还存在快速失败机制，即当Broker收到客户端的请求后会将消息先放入队列，然后顺序执行，如果一条消息队列中等待超过200ms就会启动快速失败，向客户端返回[TIMEOUT_CLEAN_QUEUE]broker busy，这个在本文的第3部分会详细介绍。

在RocketMQ客户端遇到网络超时，通常可以考虑一些应用本身的垃圾回收，是否由于GC的停顿时间导致的消息发送超时，这个我在测试环境进行压力测试时遇到过，但生产环境暂时没有遇到过，大家稍微留意一下。

在RocketMQ中通常遇到网络超时，通常与网络的抖动有关系，但由于我对网络不是特别擅长，故暂时无法找到直接证据，但能找到一些间接证据，例如在一个应用中同时连接了kafka、RocketMQ集群，发现在出现超时的同一时间发现连接到RocketMQ集群内所有Broker，连接到kafka集群都出现了超时。

但出现网络超时，我们总得解决，那有什么解决方案吗？

我们对消息中间件的最低期望就是高并发低延迟，从上面的消息发送耗时分布情况也可以看出RocketMQ确实符合我们的期望，绝大部分请求都是在微妙级别内，故我给出的方案时，减少消息发送的超时时间，增加重试次数，并增加快速失败的最大等待时长。具体措施如下：

• 增加Broker端快速失败的时长，建议为1000，在broker的配置文件中增加如下配