问题出现在前司的项目上,虽然已经离职一年多了,但有问题经常会找到我帮忙处理,并支付一点辛苦费。
项目是采用 springCloud 微服务创建的,目前有五六个服务分布在几台服务器上。
这次的问题现象是,用户创建订单后,会莫名其妙自动取消,明白问题后,首先检查该问题订单的服务日志,日志一切正常,正常下单,正常支付,正常修改订单状态。
然后检查代码,发现在另一个服务上,有一个定时任务,采用 spring 的定时任务,通过时间轮来每分钟读取数据库,获取超过设定的事件后还没有支付的订单,然后取消,而这个业务的自动取消设置的未支付 3 分钟后自动取消。顺便提一下,我感觉这种每分钟读取一次数据库来取消订单的做法有点 low,当时在职的时候想去优化一下,但一直没时间,直到拖了我三个月工资后,我提桶跑路(代码和人有一个能跑就行)。
然而这个跑定时任务的服务在另一台服务器上,检查了定时任务的日志,发现定时任务读取未支付订单时,把这单已经支付了的订单给读取出来了,我觉得很不可思议,数据库里检查了一下订单支付时间和订单的取消时间,竟然相差 3 分钟,也就是说,这个订单在支付完成三分钟后,定时任务读取未支付订单把它读取出来了,并做了取消订单的操作。
我又检查了几遍日志和代码,发现代码确实没有问题,订单被取消前,也没有其他的地方修改订单的状态,但一个支付成功的订单就这么被识别为未支付的订单了,这就奇怪了,花费了两三个小时反复检查日志和代码后,我给前司对接的人说,这大概是个灵异事件。
前司同事提议要不换成测试环境再试试,我说可以,然后切换到测试服务器准备查看实时日志,过了一会儿,前司同事给我发来一个截图,上面是新下的一个订单,她特别标记出来了下单时间,和她当时的系统时间,竟然对不上,下单时间竟然比当前时间还早三分钟。
我一下想到一个可能,我去那台业务服务器上查看了当前时间,又去定时任务那台服务器看了下时间,竟然相差 3 分钟,而且定时任务的服务器时间是正确的北京时间,定时任务服务器的时间比北京时间慢了 3 分钟!
一下子就都说得通了,这三分钟的时间差让我耗了两个小时检查代码和日志,业务服务器下单后,下单时间比实际的当前时间早了三分钟,在用户支付的间隙,正常时间服务器跑的定时任务读取超过三分钟的订单自动取消,读取到了这个订单,就造成了用户那边支付完成,定时任务又执行读取好的订单列表去取消。
真相大白后,我准备修改时间不对的服务器时间,检查时区,发现这台服务器的时区是:Time zone: Asia/Shanghai (CST, +0800),而那台正常时间的服务器,时区也是:Time zone: Asia/Shanghai (CST, +0800),但同一个时区,两台服务器获取到的 Universal time 竟然会相差三分钟,网上搜索了这个问题,发现并没有搜索到结果,只好手动卡点设置时间与北京时间同步,如果有知道这个问题原因的小伙伴,麻烦给我解惑一下,谢谢~
5 条评论
不错不错,我喜欢看 www.jiwenlaw.com
想想你的文章写的特别好
看的我热血沸腾啊
不错不错,我喜欢看 https://www.jiwenlaw.com/
看的我热血沸腾啊