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