性能调优篇-困扰我半年多的RocketMQ-timeout-exception-终于被破解了

1、网络超时现象

时不时总是接到项目组反馈说生产环境MQ发送超时，客户端相关的日志截图如下：

今天的故事将从张图开始。

2、问题排查

2.1 初步分析

上图中有两条非常关键日志：

• invokeSync：wait response timeout exception
  网络调用超时

• recive response,but not matched any request
  这条日志非常之关键，表示尽管客户端在获取服务端返回结果时超时了，但客户端最终还是能收到服务端的响应结果，只是此时客户端已经等待足够时间后放弃处理了。

关于第二条日志，我再详细阐述一下其运作机制，其实也是用一条链接发送多个请求的编程套路。一条长连接，向服务端先后发送2个请求，客户端在收到服务端响应结果时，怎么判断这个响应结果对应的是哪个请求呢？如下图所示：

客户端多个线程，通过一条连接发送了req1,req2两个请求，但在服务端通常都是多线程处理，返回结果时可能会先收到req2的响应，那客户端如何识别服务端返回的数据是对应哪个请求的呢？

解决办法是客户端在发送请求之前，会为该请求生成一个本机器唯一的请求id(requestId)，并且会采用Future模式，将requestId与Future对象放入一个Map中，然后将reqestId放入请求体中，服务端在返回响应结果时将请求ID原封不动的放入到响应结果中，当客户端收到响应时，先界面出requestId，然后从缓存中找到对应的Future对象，唤醒业务线程，将返回结构通知给调用方，完成整个通信。

故从这里能看到，客户端在指定时间内没有收到服务端的请求，但最终还是能收到，矛头直接指向Broker端，是不是Broker有瓶颈，处理很慢导致的。

2.2 Broker端处理瓶颈分析

在我的“经验”中，RocketMQ消息发送如果出现瓶颈，通常会返回各种各样的Broker Busy，而且可以通过跟踪Broker端写入PageCache的数据指标来判断Broker是否遇到了瓶颈。

grep "PAGEC