有一天，运营团队的老大苗哥急匆匆赶到部找到项目部的老大费哥，直言不讳地说:“兄弟，我们后台设置的订单是用户签收七天后系统自动确认收货，但是现在有小伙伴回应，用户签收三天后收货。这是怎么回事？你帮帮我哥哥。”
飞哥说:“好，我来处理，小米，你负责定位这件事”。
于是我放下手头的工作，着手处理。
行动由于公司订单的自动接收是每天凌晨1点被一个预定任务扫描的，所以我就去找了这个预定任务“OrderSigningJob”开始分析代码。发现开发这一块的兄弟是根据订单的“发货时间”自动确认收货的。怪不得用户签收后三天就收到货了，我就开始改造了。
第一次改造从存储的第三方物流记录表中，将原来的“交货时间”改为“签收时间”，代码如下:
改造完成后，部分订单正常签约，但发现定时器频繁上报接口超时:
第二次改造通过一路调查，发现如下界面在提供物流服务时已经报告超时，截图如下:
继续分析为什么这个接口总是报超时。看完代码，没有不必要的操作，就是页面查询数据库，打包成vo，但是只花了7秒多就返回了。然后我们把sql语句拿出来，放在数据库软件的执行下:
我们看一下带“Explain”的执行计划，发现三个字段都没有索引，state明显是枚举类型。为什么要用“Like”语法来改造？
改造后看了一下执行计划，索引打了，但是上线后发现界面还是报超时。
第三次改造开始分析，打开日志看看。一次查询1000条数据，返回的数据约为400kb，但业务实际上只需要订单号，于是创建了一个新的接口只返回订单号，如下图:
再试一次或超时。
第四次改造这个预定任务每晚1: 00执行一次，每1000次执行一次，已知一天最高订单量在1000左右，于是我和业务沟通，把预定任务改为每小时执行一次，每小时处理50条记录。
结果预定任务正常，没有像以前那样频繁报错。
注意最好是一点一点的改原码，而不是一下子全改，就像经典的“[S2/]漏管越来越漏”。写代码的时候，一定要记住设计原则“对扩展开放，对修改封闭”中的开放封闭原则。
写在最后[/s2/]好兄弟可以赞一下，关注我的微信官方账号“javaAnswer”，都是干货。
最新评论