来源：等你回来，www.cnblogs.com/yougewe??/p/8975550.html某功能上线后，某数据量急剧下降，让我们紧张！考察的过程也是学习的过程！不管结果如何，方法论都可以借鉴~1.确认问题的真实性？数据部告诉我，某数据量下降严重，我当时就知道问题的严重性了。而这个问题是在我的功能上线后出现的。我的第一反应是，我的代码有什么问题？但是还是需要按照流程，通过各种维度的数据来对比请求量和实际落地量。确认问题！其实在这个过程中，我们并没有确认我们的数据量下降了。但这也离不开数据的下滑。只能进行下一步！2、查代码，找有经验的同学，对比一下原来功能的区别？其实这一步感觉有点盲目。因为第一步的调查没有找到足够的证据证明问题出在我们身上，但问题是期间只有我们一直在线，所以我们只能反思自己。不过幸运的是，这个过程真的很有用。真的发现了自己埋的一个坑，这个坑确实会导致数据量下降。快点修好它！然后他松了一口气，以为事情已经解决了。其实不然，数据量还是不能增加。这太尴尬了！我已经开始怀疑人生了，难道代码没有贴出来？网上和本地有区别吗？测试环境反复测试正确。真想直接把测试环境代码放到网上，哎，算了，很多东西是不会以人的意志为转移的，还是理性点吧！不要试图寻找出路！3.直接坐在dba旁边，让我们时刻关注数据量？自查已经救不了自己了，还是去找dba吧。请帮我统计一下上线后数据量的变化。结果是没有太大区别。我想可能是因为时间太短，看不出有什么变化，所以以后再算吧。还是没有变化！我的天，锅还在。大量的数据是不够的，所以我会用我的帐户来测试它。运行完成后，观察数据，发现有时有有时没有！好吧，我什么也不能说。4.本地调试？本来以为是线上的问题，加急处理就好了。然而，事实却出乎我的意料。将验证直接交给在线是对用户的不负责任，也是对数据的不负责任。让我们从本地开始。本地调试用VPN有点烦，不过不管怎样，还是能跑的。没问题！这很尴尬。那么，就进入下一个话题吧！5、线上环境配置和测试环境有区别吗？然后我们尝试找出不同点，哪怕多了一个文件，某个文件的变化时间不一致，我们都想试试看！当然，为了安全起见，我们还是不能直接在线验证，除非有足够的证据证明在线配置有问题。当然，我们最终也没有找到这样的证据。我们只是把线上的东西都搬到了测试环境去验证，结果畅通无阻！还有一个理由可以证明这条路是行不通的。之前配置好的东西会不会自己坏掉？不可能的。这条路死定了！6.实在不行，只能改代码在线调试？调试的第一步就是互相登录！将完整的日志添加到之前请求的不完整部分，再发送一个版本！有了日志，有据可查，但真的是一时兴起失误，日志没有打错，把参数打印成内存地址就可以了。日志改完后，测试一下，继续用自己的账号。还是一样，有时候能进去有时候进不去（监控就是给dba设置一个临时的kafkaconsumer，然后把数据拉出来看看）！怎么样？会不会是某些机器坏了？分配给坏机器的请求将失败，而分配给正确机器的请求将是正确的。然后我花了很长时间做数据验证。我以为是方向，结果被叫回来了。7.如果没有，我们去拿包好吗？tcpdump，网络流量抓包神器，lsof助攻。抓包只是为了确认一个问题。客户端机器已向服务器机器发送请求，网络流量正常！然后证明客户端机器与服务器有大量的长连接，数据流收发正常（syn）。这至少说明客户端没有问题！那么就剩下一个问题了，那就是服务器有问题！我们坚信，当然要有证据。同样的方法，我们在服务器机器上进行了一次反向抓包，然后从客户端抓包，非常顺利！前额。..8.不行不行，重启机器？不，我说的是重启服务。最近不是有变化吗？按理说谁改谁重启。然而，这是没有用的，因为之前的版本已经重启了n次了。那个怎么样？剩下的就是重启服务器，kafka就可以服务了。死马当活马医！重启后，验证一下。结果，似乎有成有败！9、把异步请求改成同步请求？我又没思路了，我不甘心，为什么测试环境好好的，上线了就不行了？再想想，哪里不一样了？得出的结论是线上并发量大，测试环境小。然后我发现这段代码是由一个异步线程完成的。难不成这里有问题？不管了，试试改成同步请求吧。又一版！还别说，切换到同步后，虽然用户请求基本慢的要死，但是发现确实存在kafka请求。难道真的是因为这个，那我们就不能这样改了，用户体验第一，为了这件事从异步改成同步，我们绕不开。改回去继续做其他事情！10、回到测试环境，压测并发？改回异步后，又回到了原来有成功有失败的情况。既然怀疑是线上高并发造成的，那为什么不在高并发压力的测试环境中测试一下呢？使用shell脚本快速编写循环请求脚本。向kafka发送大量请求后，没有任何异常，就取消了并发问题。(for,nohupa.sh>/dev/null2&>1&)n次模拟n个并发请求11.我们再仔细检查一下代码？不知道查了多少遍，还是得查，不然怎么办？让几个人一起看代码！然而，这是没有用的。12、不管用户行为，直接以命令行的形式操作请求？用户行为虽然是最真实的验证，但也是比较麻烦的验证。我们先抛开各种中间环节，直接向kafka服务器发起请求吧！有两种方式，1.使用当前代码请求，2.使用Kafka自带的请求方式请求。结果，得到了两个不同的结果。代码请求数据不成功，使用kafka自带的请求方式毫秒级响应。咦，这又让我怀疑代码了？13、无处可去，我们再看看数据好吗？实在是没什么想法，只能再看看资料打发时间。意外发生在您意想不到的时候。数据已恢复正常！我擦！时间和事件倒转是因为kafka重启，导致数据恢复。好了，问题定位了，kafka卡住了。看不下去了，发个总结邮件，我们先回去洗漱睡觉吧！14.kafka为什么会卡顿？这才是问题的根源！只是我们没有力气再往前了！结论是主题请求量太大，分区太小，导致吞吐量下降。将分区改大后，终于恢复正常了！嗯，看来自己做了很多无用功，没办法啊！最新2TB技术干货：包括架构师实战教程、大数据、Docker容器、系统运维、数据库、redis、MogoDB、电子书、Java基础课程、Java实战项目、ELKStack、机器学习、BAT面试精读讲座视频等，只需在“民工哥科技之路”微信公众号对话框回复关键字：1024即可获取所有信息。
