上周的总结中提到了,解决订单状态显示延迟的问题。
1.上周通过review代码,解决主从延迟导致的原因。
2.通过一些日志观察,发现数据已经扭转成功了。并且反馈问题的数据都是交通银行的秒批。怀疑是多个脚本同时改一条数据导致的。于是在脚本修改状态的时候,where语句加了一个判断,如果status!=当前查询的值,就不再修改,说明此条数据已经在别的地方被扭转了。
3.经过了2次修复,还有少量订单出现问题。百思不得。好在上一次又加了更详细的日志。
saveMoniter的方法加了getLastSql日志.
查日志的时候,合伙人的进度查询接口调用错了,调用的是信用卡的进度查询,导致日志打到了信用卡模块的日志,在合伙人一直查不到日志,导致问题排查的方向错误。
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,用户每次进件的状态值都是覆盖的,不会对同一条进件做任何过滤。所以用户进件成功后,有再去重复进件同一家银行的卡,会将状态值覆盖掉。
至此,破案
网友评论