别说，改为同步后，虽然用户请求基本都慢死了，但是发现kafka请求确实存在了。难道真的是因为这个，那我们也不能这么改啊，用户体验是第一位的，为了这事改异步为同步，咱得吃不了兜着在意啊。改回来继续其他的吧！
10. 再回测试环境，压测并发？
改还原为异步后，又回到当初有成功有失败境地了。
既然怀疑线上高并发导致，那为什么不在测试环境高并发一下？用shell脚本快速写了一个循环请求脚本，大量请求到kafka后，并无一丝异常，到此并发问题取消。
11. 再来细细检查代码吧？
都不知道查了几遍了，但是还是要查啊，不然咋整呢，几个人一起看代码呗！
然而这并没有什么卵用。
12. 抛开用户行为，直接以命令行形式操作请求？
虽然用户行为是最真实的验证，但是也是比较麻烦的验证。
我们就抛开各种中间环节，直接向kafka服务器发起请求！
分两种方式，1 用现在的代码去请求，2 用kafka自带的请求方式请求。结果得到两个不同的结果，用代码的方式请求的数据，没有成功，用kafka自己的请求方式，则毫秒级响应。哎，这是让我又怀疑代码？
13. 已走投无路，让我们再看一眼数据吧？
真的是没有思路了，只能再来看看数据，当打发时间了。
意外就在你想不到的时候发生了。数据已经恢复正常了！我擦！
倒推时间，倒推事件，是由于kafka重启，导致数据回升的。
好吧，问题已经定位，kafka卡顿导致。咱们已经熬不住，发个结论邮件，就先回去洗洗睡吧！
14. 为什么kafka会卡顿？
这才是问题的根本！只是我们当时已经没有力气再往下搞了！
由于topic请求量过大，而partition过小，导致吞吐量下降。将partition改大之后，终于真正恢复正常！
额，好像做了很多无用功，没办法 ！