这个步调其实，昆山软件公司，昆山软件开发，是有点盲目标感受。因为第一步的排查并没有找到足够的证明说明问题出在我们，可是问题在于期间只有我们上过线，所以只能自我反省了。

不外幸好，这进程还真有用，果然发明白本身埋的一个坑，此坑确实会导致该数据量的下滑。赶忙修掉呗！

然后松了一口吻，觉得搞好了。其实否则，数据量依然上不去。这就难过了！

我已经开始猜疑人生，莫非代码没发上去？莫非线上和当地某个处所纷歧样？测试情况重复测试正确无误。我真想直接把测试情况代码弄到线上去，哎，算了吧，许多对象是不会以人的意志为转移的，咱们照旧理性点！别谋出路吧！

3. 直接坐到dba旁边去吧，让我们随时存眷数据量？

自我排查已经救不了本身了，那就上dba哪里。贫苦帮我统计下上线后，数据量的变革，功效是没多大不同。心想有大概是时间太短，看不出变革，等会儿再统计吧。依然没有变革！我的神呐，定了锅还在。

大的数据量不可，那我用本身的账号来测试吧，操纵完成后，调查数据，发明有时有有时无！额，说不出啥了。

4. 当地调试吧？

原本觉得，是线上问题，紧张处理惩罚下就好了。然而事实却超出了我的预料，将验证直接交给线上，是对用户的不认真，是对数据的不认真。咱们照旧从当地做起吧。

当地调试要走vpn，有点烦，但不管怎么样，照旧跑起来了。没问题啊！这难过了。

然后，引出下一个议题！

5. 线上情况设置与测试情况纷歧样？

然后我们尽力找出个中的差异点，哪怕是多了一个文件，某个文件的变动时间点纷歧致，我们都想去试一下！虽然了，为了稳妥起见，我们照旧不能直接在线上验证的，除非有足够的证听说明线上的设置是有问题的。虽然我们最终并没有找到这样的证据，只是将线上的所有对象都搬到测试情况来验证，功效是流畅无阻！

尚有一个证明此路不通的来由，之前的设置跑得好好的对象，莫非会本身坏掉？不行能吧。此路不通！

6. 实在不可了，只能改代码线上调试？

调试第一步，各自打日志！把之前请求打印不全的处所，加上完整日志，再发一版吧！有了日志，就有证据，可是真的是急中生错啊，日志居然打得差池，将参数打印为了内存地点也真是够了。

日志改好后，测试呗，继承用本身的账号。照旧一样，有时能能进有时不能（监控手段为dba起一个姑且的kafka消费者，然后将数据拉出来看）！那咋整呢？

莫非是有的呆板坏了？分派到坏的呆板上去的请求就失败，分派到正确呆板的上去的请求就正确。然后吭哧吭哧搞了半天的数据验证，曾经觉得这是偏向，功效又被打回。

7. 不可咱们就抓包吧？

tcpdump，一个网络流抓包神器，lsof助攻一下。

抓包只是为了确认一个问题，客户呆板有发送请求随处事端呆板，网络流正常运转！然后证明，客户端呆板有大量长毗连随处事器，数据流发送吸收正常（syn）。这至少说明白一点，客户端是没有问题的！那么就还剩一个问题，那就是处事端出问题了！我们坚信，虽然要有证据嘛。

同理，我们在处事端呆板长举办反向抓包，然后抓到了来自客户端的包，很流通嘛！额。。。

8. 不可，没有思路了，重启呆板吧？

不，我说的是重启处事。最近不是有窜改嘛，按理谁窜改重启谁。然而这是没有用的，因为之前的屡次宣布早已重启了n次。那咋整呢。只剩重启处事端，kafka处事了呗，死马当活马医吧！

重启后，验证呗。功效貌似照旧发明有乐成，有失败！

9. 改异步请求为同步请求？

又没思路了，我不宁肯甘心呐，为啥测试情况好好的，到线上就不可了呢？再想想不同在那边？

得出的结论是，线上并发大，测试情况量无。然后发明这一块代码是由异步线程做的，会不会是这里有问题？

不管了，改成同步请求试试吧。再来一版！