因为一次功能上线后，致使某数据量急剧下滑，给咱们紧张的呢！排查过程也是个学习过程！抛开结果，方法论可供参考～shell
被数据部门告知，某数据量下滑严重，当时即知道问题的严重性。且该问题是在个人功能上线后产生，第一反应就是，我代码哪里写错了？ 可是，还得按流程来，经过各类维度数据对比请求量，实际落地量。确认问题！服务器
其实该过程当中，咱们并无确认本身的数据量下滑。可是这也脱不了数据下滑的干系。只能进行下一步！markdown
这个步骤其实，是有点盲目的感受。由于第一步的排查并无找到足够的证实说明问题出在咱们，可是问题在于期间只有咱们上过线，因此只能自我检讨了。网络
不过幸亏，这过程还真有用，果然发现了本身埋的一个坑，此坑确实会致使该数据量的下滑。赶忙修掉呗！并发
而后松了一口气，觉得搞好了。其实否则，数据量依然上不去。这就尴尬了！异步
我已经开始怀疑人生，难道代码没发上去？难道线上和本地某个地方不同？测试环境反复测试正确无误。我真想直接把测试环境代码弄到线上去，哎，算了吧，不少东西是不会以人的意志为转移的，我们仍是理性点！别谋出路吧！tcp
自我排查已经救不了本身了，那就上dba那里。麻烦帮我统计下上线后，数据量的变化，结果是没多大差异。心想有多是时间过短，看不出变化，等会儿再统计吧。依然没有变化！个人神呐，定了锅还在。高并发
大的数据量不行，那我用本身的帐号来测试吧，操做完成后，观察数据，发现有时有有时无！额，说不出啥了。学习
本来觉得，是线上问题，紧急处理下就行了。然而事实却超出了个人预料，将验证直接交给线上，是对用户的不负责，是对数据的不负责。我们仍是从本地作起吧。测试
本地调试要走vpn，有点烦，但无论怎么样，仍是跑起来了。没问题啊！这尴尬了。
而后，引出下一个议题！
而后咱们努力找出其中的不一样点，哪怕是多了一个文件，某个文件的更改时间点不一致，咱们都想去试一下！固然了，为了稳妥起见，咱们仍是不能直接在线上验证的，除非有足够的证听说明线上的配置是有问题的。固然咱们最终并无找到这样的证据，只是将线上的全部东西都搬到测试环境来验证，结果是畅通无阻！
还有一个证实此路不通的理由，以前的配置跑得好好的东西，难道会本身坏掉？不可能吧。此路不通！
调试第一步，各自打日志！把以前请求打印不全的地方，加上完整日志，再发一版吧！有了日志，就有证据，可是真的是急中生错啊，日志竟然打得不对，将参数打印为了内存地址也真是够了。
日志改好后，测试呗，继续用本身的帐号。仍是同样，有时能能进有时不能（监控手段为dba起一个临时的kafka消费者，而后将数据拉出来看）！那咋整呢？
难道是有的机器坏了？分配到坏的机器上去的请求就失败，分配到正确机器的上去的请求就正确。而后吭哧吭哧搞了半天的数据验证，曾经觉得这是方向，结果又被打回。
tcpdump，一个网络流抓包神器，lsof助攻一下。
抓包只是为了确认一个问题，客户机器有发送请求到服务端机器，网络流正常运转！而后证实，客户端机器有大量长链接到服务器，数据流发送接收正常（syn）。这至少说明了一点，客户端是没有问题的！那么就还剩一个问题，那就是服务端出问题了！咱们坚信，固然要有证据嘛。
同理，咱们在服务端机器上进行反向抓包，而后抓到了来自客户端的包，很流畅嘛！额。。。
不，我说的是重启服务。最近不是有改动嘛，按理谁改动重启谁。然而这是没有用的，由于以前的几回发布早已重启了n次。那咋整呢。只剩重启服务端，kafka服务了呗，死马当活马医吧！
重启后，验证呗。结果貌似仍是发现有成功，有失败！
又没思路了，我不甘心呐，为啥测试环境好好的，到线上就不行了呢？再想一想差异在哪里？
得出的结论是，线上并发大，测试环境量无。而后发现这一块代码是由异步线程作的，会不会是这里有问题？
无论了，改为同步请求试试吧。再来一版！
别说，改成同步后，虽然用户请求基本都慢死了，可是发现kafka请求确实存在了。难道真的是由于这个，那咱们也不能这么改啊，用户体验是第一位的，为了这事改异步为同步，咱得吃不了兜着走啊。改回来继续其余的吧！
改还原为异步后，又回到当初有成功有失败境地了。
既然怀疑线上高并发致使，那为何不在测试环境高并发压测一下呢？用shell脚本快速写了一个循环请求脚本，大量请求到kafka后，并没有一丝异常，到此并发问题取消。（for，nohup a.sh > /dev/null 2&>1 &）n 次即模拟n个并发请求
都不知道查了几遍了，可是仍是要查啊，否则咋整呢，几我的一块儿看代码呗！
然而这并无什么卵用。
虽然用户行为是最真实的验证，可是也是比较麻烦的验证。
咱们就抛开各类中间环节，直接向kafka服务器发起请求！
分两种方式，1 用如今的代码去请求，2 用kafka自带的请求方式请求。结果获得两个不一样的结果，用代码的方式请求的数据，没有成功，用kafka本身的请求方式，则毫秒级响应。哎，这是让我又怀疑代码？
真的是没有思路了，只能再来看看数据，当打发时间了。
意外就在你想不到的时候发生了。数据已经恢复正常了！我擦！
倒推时间，倒推事件，是因为kafka重启，致使数据回升的。
好吧，问题已经定位，kafka卡顿致使。我们已经熬不住了，发个结论邮件，就先回去洗洗睡吧！
这才是问题的根本！只是咱们当时已经没有力气再往下搞了！
结论是因为topic请求量过大，而partition太小，致使吞吐量降低。将partition改大以后，终于真正恢复正常！
额，好像作了不少无用功，没办法 ！