消息发送超时，通常客户端的日志如下： 客户端报消息发送超时，通常第一怀疑的对象是 RocketMQ 服务器，是不是 Broker 性能出现了抖动，无法抗住当前的量。 那我们如何来排查 RocketMQ 当前是否有性能瓶颈呢？ 首先我们执行如下命令查看 RocketMQ 消息写入的耗时分布情况： cd /${USER.HOME}/logs/rocketmqlogs/ grep -n 'PAGECACHERT' store store.log | more 输出结果如下所示： RocketMQ 会每一分钟打印前一分钟内消息发送的耗时情况分布，我们从这里就能窥 探 RocketMQ 消息写入是否存在明细的性能瓶颈，其区间如下： 本文来自『中间件兴趣圈』公众号，仅作技术交流，未授权任何商业行为。 1.17 消息发送常见问题与解决方案 < 158  [<=0ms] 小于 0ms，即微妙级别的。  [0~10ms] 10ms 小。  于 50ms 的个数。 其他区间显示，绝大多数会落在微妙级别完成，按照笔者的经验如果 100-200ms 及 以上的区间超过 20 个后，说明 Broker 确实存在一定的瓶颈，如果只是少数几个，说明这 个是内存或 pagecache 的抖动，问题不大。 通常情况下超时通常与 Broker 端的处理能力关系不大，还有另外一个佐证，在 RocketMQ broker 中还存在快速失败机制，即当

开源版本。 诞生 RocketMQ起源于阿里巴巴。阿里巴巴最初由于业务需求，需要使用消息中间件。早期使用过Notify ActiveMQ等。但在需求不断膨胀的情况下，ActiveMQ IO模块遇到了瓶颈，几经努力但改善成果不 。这时正值Kafka流行，于是引起了阿里巴巴开发团队的注意，对kafka的无限消息堆积，高效持久化 度等特性非常赞赏。但不幸的是，Kafka不能满足他们的要求，特别是在低延迟和高可靠性方面。在