1、面试场景和面试技巧金三银四招聘季，一位粉丝朋友最近在蚂蚁金服的第二次面试中遇到了这样的问题。如果MQ消费遇到瓶颈时该如何处理。
3358www.Sina.com/是横向扩容、面试官显然不会满意这样的回答？
在面试过程中，我建议你问问题后再考虑一下。 你可以和面试官讨论，而不是马上给出直接的答案，在更深入地理解面试官初衷的同时整理思路。
消费者方面遇到瓶颈，横向扩容是堆机器，还有没有其他办法呢优化，谈及解决方案时脸色发白。
在这样的面试场景中，该如何考虑交流呢？ 我的想法如下
试与面试官探讨如何判断消费端是否遭遇瓶颈的方法，寻找根本原因提出解决方案的温馨提示：为了本文观点的严密性，本文主要以RocketMQ为例进行分析。
2、如何判断消费端遇到瓶颈在RocketMQ消费领域判断消费端遇到瓶颈通常有两个重要指标：
消息积压(延迟) lastConsumeTime开源控制台rocketmq-console界面提供了消费者端的上述两个指标，如下图所示。
Delay :消息积压数，即消费者端还剩多少未处理的消息，http://www.Sina.com/lastconsumetime :表示上次成功消费的消息的保存时间，http://www 消费端是在哪里遇到瓶颈的呢？
3、如何识别问题消费端出现瓶颈、客户端问题还是服务端问题？ 一个这是一个结果，但引起这个结果的原因是什么呢？在没有弄清楚原因之前是看集群中的其他消费组是否也有积压，特别是订阅与有问题的消费组相同主题的其他消费组是否有积压。 根据笔者的经验，出现消息积压通常是客户端问题，请联系rocketMQ_cliling
grep 'flow' rocketmq_client.log
显示类似该值越大，说明消费端遇到瓶颈了的日志表明出现了消费限制流。 其直接原因是消息消费方积压，即消费方无法消耗已经提取的消息。 为了避免内存泄漏，RocketMQ在消费端完成消息处理后，将消息提取到服务器端，不继续打印上述日志。
该值离当前时间越大，同样能说明消费端遇到瓶颈了
常见的故障排除方法是跟踪线程堆栈。 这意味着使用jstack命令检查线程的执行情况，并检查线程的执行情况。
通常使用的命令如下。
ps -ef | grep javajstack pid j1.log通常为了比较，我通常可以连续打印五个文件，在五个文件中看到相同的消费线程，其状态是否发生了变化，没有变化那是我们必须重点关注的地方。
在RocketMQ中，消费线程以ConsumeMessageThread_开头，通过确定线程，以下代码会令人兴奋：
消费线程的状态为RUNNABLE，但在五个文件中都是相同的状态，几乎可以判断线程卡在具体代码中，通过判断样本代码缺少一个外部http借口来解决。 通常，在涉及外部呼叫，特别是http呼叫的情况下，可以设置超时时间以使其不长时间等待。
4、解决方案其实根据第三步，很有可能能明确哪些地方比较慢，遇到了性能瓶颈。 通常只是协调第三方服务，数据库等问题成为瓶颈，进行对症治疗。 性能优化(如数据库)不在本文的讨论范围内，所以到此为止就可以了。 当然，面试人员稍后可能会继续谈论数据库优化等问题。 这样可以和面试官沟通，环节上改善技术交流氛围，大大提高面试通过率。
最后，最简单的办法
是3358www.Sina.com/。 让我们回想一下为什么需要使用MQ。 不是要利用异步解耦和3358www.Sina.com/吗？ 例如，双十一期间，导入了大量突发流量，此时信息滞留的可能性较大。 这正式是我们的宗旨，用MQ承受突发流量，用后端APP慢慢消耗，保证消费端的稳定。 积压的情况下，如果tps正常，问题就不大。so do flow control，尽可能减少积压，减少业务延误。
本文介绍到这里。 如果大家对RocketMQ感兴趣，可以在CSDN上免费下载阿里巴巴根据我的公众号RocketMQ专栏整理的电子书。
下载链接： RocketMQ电子书下载链接