数据库-事故

背景

下单后,这里就会创建一个订单,这里的订单涉及到几个状态,订单创建订单支付订单服务中完成订单完成

用户在平台下单,首先当然需要填写一些信息,然后点击提交表单,提交后,就会跳转到一个支付页面,同时在支付页面也会有一个支付截止时间,

在这个截止时间内完成支付,订单状态就会进入到订单支付的状态,这个截止时间字段,对应数据表就用 endTime 表示,然后 endTime = createTime + 30 min

最近需要添加一个新的功能,就是能够支持自动退款的操作。

要求如果处于服务中的订单,要是 30 天没有提交完成的信息,那么就会给用户自动退款。

这个时候,就可以继续复用上面提到的 endTime,只需要设置一下endTime = endTime + 30 Day

通过写一个定时器,每隔几分钟查询订单表,判断是否有处于服务中的订单,并且 endTime 小于当前时间的,如果查询到了的话,就说明这个订单已经超过 30 天的服务周期,那么就执行退款流程。

这个流程上其实是没有问题的,出问题的是在一些历史的订单,因为对于一些历史处于服务中的订单,它的endTime 还是支付截止时间,而不是服务截止时间,即 endTime = createTime + 30 min

所以在自动退款功能上线后,会把历史服务中的订单也扫描出来,然后执行退款操作,但是此时退款操作并没有完成,而是失败了,

因为写的部分逻辑对旧订单没有适配,从而触发了写的兜底的错误报警,造成所有退款操作都被回滚了。

事故复盘

第一时间先定位到异常代码,然后进行解决。

其实通过上述的描述,我们也可以发现根本的问题,即对于一些历史订单处理上出现问题,

这个时候,需要做的就是通过对数据库进行刷数操作,把历史订单的 endTime 增加 30 天,比如执行这样一个SQL语句:

UPDATE order SET end_time = DATE_ADD(create_time, INTERVAL 30 DAY)  WHERE STATUS="服务中"

同时在进行订单状态的变更时,

如果该状态不需要使用到 end_time 时,那么需要及时将其清空,

而不能让其存储在数据库中,这样也可以避免以后可能再次发生。

order.endTime = NULL;
order.updateById();

这次事故的发生没有认真观察到之前 end_time 埋下的祸根。

数据库-事故

上一篇:nginx源码分析之网络初始化


下一篇:微信小程序制作个人简历