我先屏蔽了该段代码，重启服务后发现之前timeout的接口马上毫秒级返回了数据。多次尝试跑通了全支付流程，再无mongo查询异常出现。之后和写这段代码的前同事沟通后确认该代码是可以删除的，至此该问题尘埃落地。
所以，之前时好时坏，只是因为数据库顽强的求生欲而已。本质是因为那段历史遗留代码会非常频繁地读写数据库，导致其他请求排队等待。通过在这次排查问题，我又一次对分析问题有了新的思考：
对一些临时接手后有大量历史遗留问题的项目，一定要深入细节，不能因为是继承的代码，默认它是正常无错的，关于那段存储人社数据的代码我也曾经怀疑过，但是没有去深究，默认了它一直使用就是不能轻易改动的。
结对编程是很重要的。这在一些其他公司已经很常见了，对于小的创业公司，我们考虑更多的是一个工程师去support一个或者多个完整的项目，有时候个人的思路是非常有限的，常见的问题是很容易通过自身努力解决，而一些思路有死角的疑难杂症可能需要群策。我这里说的结对编程特指对该项目负责且全程参与的人。因为往往一些google都很难找到特别接近的解决方案的问题，往往有项目自身特殊原因。
God is in details.God bless my code.