上周的总结中提到了，解决订单状态显示延迟的问题。
1.上周通过review代码，解决主从延迟导致的原因。
2.通过一些日志观察，发现数据已经扭转成功了。并且反馈问题的数据都是交通银行的秒批。怀疑是多个脚本同时改一条数据导致的。于是在脚本修改状态的时候，where语句加了一个判断，如果status!=当前查询的值，就不再修改，说明此条数据已经在别的地方被扭转了。
3.经过了2次修复，还有少量订单出现问题。百思不得。好在上一次又加了更详细的日志。
saveMoniter的方法加了getLastSql日志.
image.png
查日志的时候，合伙人的进度查询接口调用错了，调用的是信用卡的进度查询，导致日志打到了信用卡模块的日志，在合伙人一直查不到日志，导致问题排查的方向错误。
3个重要时间:
进件表: 进件时间(15:38:46) progress_status=3(等待批卡查询),update_time:16:22:28
进度查询表:16:19:45进度查询成功,并且该银行是广发银行，是手动查询银行，非自动.
日志:16:19:18秒，有脚本自动匹配日志，此时匹配的结果是3
16:19:18脚本自动进件同步日志
通过kb的nginx日志，发现用户没有找到用户提交进度查询的接口日志(原因是kb只记录从页面访问我们服务的日志，提交是ajax异步请求的，kb不会记录)
但用户在进件进度查询之前，就一条时间相近的访问日志。仔细观察发现，用户是通过分享进入的，所以kb记录的是用户请求分享接口，通过refere看到用户的来源是progress/query，进度查询首页。
16:18:57
16:18::57的referrer
说明用户是由分享进入的进度查询，域名是m.rong360.com，所以解释通了自己为什么之前找不到日志。于是去信用卡模块的日志就找到了日志:
16:19:45用户主动进度查询
通过上图可以看到，用户主动查询后，sql已经记录用户的最新状态，状态已经扭转成功了，为1。然而数据库的最新结果却是3，说明有其他的地方将数据状态改了，最有可能的地方肯定是脚本。于是在脚本机器上，将所有日志都查了，没有发现改数据的sql。
百思不得姐。脑子灵光一闪，进件表的update_time时间是16:22:28，于是赶紧在kb上一看，这个时间有一个请求
image.png
image.png
用户在请求信用卡申请接口。此时猜想用户有没有可能审批成功后又重新进件呢？用户到了进件接口，可能会确认进件。于是去看了下保存进件的接口(这个接口依旧是ajax请求的，所以kb的nginx没有访问日志).果然发现了bug，用户每次进件的状态值都是覆盖的，不会对同一条进件做任何过滤。所以用户进件成功后，有再去重复进件同一家银行的卡，会将状态值覆盖掉。
至此，破案
网友评论