由于一次功能上线后，导致某数据量急剧下滑，给我们紧张的呢！排查过程也是个学习过程（这其中有大部分是领导们的功劳，不过分享给大家应该也不犯法吧，ᐓ）
1. 确认问题的真实性？
被数据部门告知，某数据量下滑严重，当时即知道问题的严重性。且该问题是在我的功能上线后产生，第一反应就是，我代码哪里写错了？ 但是，还得按流程来，通过各种维度数据对比请求量，实际落地量。确认问题！
其实该过程中，我们并没有确认自己的数据量下滑。但是这也脱不了数据下滑的干系。只能进行下一步！
2. 检查代码，找有经验的同学，对比原有功能差异点
这个步骤其实，是有点盲目的感觉。因为第一步的排查并没有找到足够的证明说明问题出在我们，但是问题在于期间只有我们上过线，所以只能自我反省了。
不过幸好，这过程还真有用，果真发现了自己埋的一个坑，此坑确实会导致该数据量的下滑。赶紧修掉呗！
然后松了一口气，以为搞好了。其实不然，数据量依然上不去。这就尴尬了！
我已经开始怀疑人生，难道代码没发上去？难道线上和本地某个地方不？测试环境反复测试正确无误。我真想直接把测试环境代码弄到线上去，哎，算了吧，很多东西是不会以人的意志为转移的，咱们还是理性点！别谋出路吧！
3. 直接坐到dba旁边去吧，让我们随时关注数据量
自我排查已经救不了自己了，上dba那里。麻烦帮我统计下上线后，数据量的变化，结果是没多大差别。心想有可能是时间太短，看不出变化，等会儿再统计吧。依然没有变化！我的神呐，定了锅还在。
大的数据量不行，那我用自己的账号来测试吧，操作完成后，观察数据，发现有时有有时无！额，说不出啥了。
4. 本地调试吧？
原本以为，是线上问题，紧急处理下就好了。然而事实却超出了我的预料，将验证直接交给线上，是对用户的不负责，是对数据的不负责。咱们还是从本地做起吧。
本地调试要走vpn，有点烦，但不管怎么样，还是跑起来了。没问题啊！这尴尬了。
然后，引出下一个议题！
5. 线上环境配置与测试环境不一样？
然后我们努力找出其中的不同点，哪怕是多了一个文件，某个文件的更改时间点不一致，我们都想去试一下！当然了，为了稳妥起见，我们还是不能直接在线上验证的，除非有足够的证据说明线上的配置是有问题的。当然我们最终并没有找到这样的证据，只是将线上的所有东西都搬到测试环境来验证，结果是畅通无阻！
还有一个证明此路不通的理由，之前的配置跑得好好的东西，难道会自己坏掉？不可能吧。此路不通！
6. 实在不行了，只能改代码线上调试？
调试第一步，各自打日志！把之前请求打印不全的地方，加上完整日志，再发一版吧！有了日志，就有证据，但是真的是急中生错啊，日志居然打得不对，将参数打印为了内存地址也真是够了。
日志改好后，测试呗，继续用自己的账号。还是一样，有时能能进有时不能（监控手段为dba起一个临时的kafka消费者，然后将数据拉出来看）那咋整呢？
难道是有的机器坏了？分配到坏的机器上去的请求就失败，分配到正确机器的上去的请求就正确。然后吭哧吭哧搞了半天，曾经以为这是方向，结果又被打回。
7. 不行咱们就抓包吧？
tcpdump，一个抓包神器，lsof助攻一下。
抓包只是为了确认一个问题，客户机器有发送请求到服务端机器，网络流正常运转！然后证明，客户端机器有大量长连接到服务器，数据流发送接收正常（syn）。这至少说明了一点，客户端是没有问题的！那么就还剩一个问题，那就是服务端出问题了！我们坚信，当然要有证据嘛。
同理，我们在服务端机器上进行反向抓包，然后抓到了来自客户端的包，很流畅嘛！额。。。
8. 不行，没有思路了，重启机器吧？
不，我说的是重启服务。最近不是有改动嘛，按理谁改动重启谁。然而这是没有用的，因为之前的几次发布早已重启了n次。那咋整呢。只剩重启服务端，kafka服务了呗，死马当活马医吧！
重启后，验证呗。结果貌似还是发现有成功，有失败！
9. 改异步请求为同步请求？
又没思路了，我不甘心呐，为啥测试环境好好的，到线上就不行了呢？再想想差别在哪里？
得出的结论是，线上并发大，测试环境量无。然后发现这一块代码是由异步线程做的，会不会是这里有问题？
不管了，改成同步请求试试吧。再来一版！