标签：事故 支付 数据库 30 订单 time endTime 退款

背景

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

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

在这个截止时间内完成支付，订单状态就会进入到订单支付的状态，这个截止时间字段，对应数据表就用 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 埋下的祸根。

标签：事故,支付,数据库,30,订单,time,endTime,退款
来源： https://www.cnblogs.com/zwtblog/p/15202781.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。