１、面试场景与面试技巧
金三银四招聘季，一位粉丝朋友最近在蚂蚁金服第二轮面试时遇到这样一个问题：若是MQ消费遇到瓶颈时该如何处理?。java
横向扩容，相比不少读者与我这位朋友同样会脱口而出，面试官显然不会满意这样的回答，而后追问道：横向扩容是堆机器，还有没有其余办法呢？面试
在面试过程当中，我的建议你们在听到问题后稍做思考，不要立马给出太直接的答案，而是应该与面试官进行探讨，一方面可更深入的理解面试官的出题初衷，同时能够给本身梳理一下思路。shell
消费端遇到瓶颈，这是一个结果，但引发这个结果的缘由是什么呢？在没有弄清楚缘由以前谈优化、解决方案都会显得很苍白。数据库
在这样的面试场景中，咱们该如何探讨交流呢？个人思路以下：后端
- 尝试与面试官探讨如何判断消费端遇到瓶颈
- 如何查找根因
- 提出解决方案
> 舒适提示：为了本文观点的严谨性，本文主要以RocketMQ为例进行剖析。性能优化
２、如何判断消费端遇到瓶颈
在RocketMQ消费领域中判断消费端遇到瓶颈一般有两个重要的指标：运维
- 消息积压数量（延迟数量）
- lastConsumeTime
在开源版本的控制台rocketmq-console界面中，能够查阅一个消费端上述两个指标，以下图所示： 
异步
- Delay：消息积压数量，即消费端还剩下多少消息未处理，该值越大，说明消费端遇到瓶颈了。
- LastConsumeTime：表示上一次成功消费的消息的存储时间，该值离当前时间越大，一样能说明消费端遇到瓶颈了。
那为何会积压呢？消费端是在哪遇到瓶颈了呢？性能
３、如何定位问题
消费端出现瓶颈，如何识别是客户端的问题仍是服务端的问题，一个最简单的办法是看集群内其余消费组是否也有积压，特别是和有问题的消费组订阅同一个主题的其余消费组是否有积压，按照笔者的经验，出现消息积压一般是客户端的问题，能够经过查询 rocketmq_client.log加以证实：优化
grep "flow" rocketmq_client.log
出现so do flow control 这样的日志，说明触发了消费的限流，其直接触发缘由：就是消息消费端积压消息，即消费端没法消费已拉取的消息，为了不内存泄露，RocketMQ在消费端没有将消息处理完成后，不会继续向服务端拉取消息，并打印上述日志。
那如何定位消费端慢在哪呢？是卡在哪行代码呢？
一般的排查方法是跟踪线程栈，即利用jstack命令查看线程运行状况，以此来探究线程的运行状况。
一般使用的命令以下：
ps -ef | grep java jstack pid > j1.log
一般为了对比，我通常会连续打印5个文件，从而能够在5个文件中查看同一个消费者线程，其状态是否变化，若是未变化，则说明该线程卡主，那就是咱们重点须要关注的地方。
在RocketMQ中，消费端线程以ConsumeMessageThread_开头，经过对线程的判断，以下代码让人为之兴奋： 消费端线程的状态是RUNNABLE，但在5个文件中其状态都是同样，基本能够判定线程卡在具体的代码，从示例代码中是卡在掉一个外部的http借口，从而加以解决，一般在涉及外部调用，特别是http调用，能够设置一个超时时间，避免长时间等待。
四、解决方案
其实根据第三步骤，大几率能明确是哪一个地方慢，遇到了性能瓶颈，一般无非就是调第三方服务，数据库等问题出现了瓶颈，而后对症下药。数据库等性能优化，并不在本文的讨论范围以内，故这里能够点到为止，固然面试官后续可能会继续聊数据库优化等话题，这样就实现了与面试官的交流互动，一环扣一环，技术交流氛围友好，面试经过率大大提升。
最后，我还想和你们探讨一个问题，出现消息积压就必定意味着遇到消费瓶颈，必定须要处理吗？
其实也否则，咱们回想一下为何须要使用MQ，不就是利用异步解耦与削峰填谷吗？例如在双十一期间，大量突发流量汇入，此时极可能致使消息积压，这正式咱们的用意，用MQ抗住突发流量，后端应用慢慢消费，保证消费端的稳定，在积压的状况下，若是tps正常，即问题不大，这个时候一般的处理方式就是横向扩容，尽量的下降积压，减小业务的延迟。
本文就介绍到这里了。若是你们对RocketMQ感兴趣，可下载个人电子书，获取线上环境运维千亿级消息流转集群的运维实战经验。 关注公众号[中间件兴趣圈]，回复RMQPDF便可获取。