首页 / PHP / 防订单重复提交策略方法

防订单重复提交策略方法

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了防订单重复提交策略方法，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3674字，纯文字阅读大概需要6分钟。

内容图文

背景

在业务开发中，我们常会面对防止重复请求的问题。当服务端对于请求的响应涉及数据的修改，或状态的变更时，可能会造成极大的危害。重复请求的后果在交易系统、售后维权，以及支付系统中尤其严重。

前台操作的抖动，快速操作，网络通信或者后端响应慢，都会增加后端重复处理的概率。前台操作去抖动和防快速操作的措施，我们首先会想到在前端做一层控制。当前端触发操作时，或弹出确认界面，或disable入口并倒计时等等，此处不细表。但前端的限制仅能解决少部分问题，且不够彻底，后端自有的防重复处理措施必不可少，义不容辞。

在接口实现中，我们常要求接口要满足幂等性，来保证多次重复请求时只有一次有效。

查询类的接口几乎总是幂等的，但在包含诸如数据插入，多模块数据更新时，达到幂等性会比较难，尤其是高并发时的幂等性要求。比如第三方支付前台回调和后台回调，第三方支付批量回调，慢性能业务逻辑（如用户提交退款申请，商家同意退货/退款等）或慢网络环境时，是重复处理的高发场景。

尝试

这里针对“用户提交退款申请”的例子，说明一下尝试过的防重复处理方法的效果。后端防重复处理的方式，我们先后尝试了三种：

（1）基于DB中退款订单状态的验证

这种方式简单直观，从DB查询出来的退款详情（包括状态）往往还可以用在后续逻辑中，没有花额外的工作专门应对重复请求的问题。

这种查询状态后进行验证的逻辑，从代码上线后就一直存在于所有含状态的业务逻辑处理中，必不可少。但对于防重复处理效果并不好：在前端添加防重复提交前，每周平均在25笔；前端优化后，每周降到7笔。这个数量占总退款申请数的3%%，一个仍然无法接受的比例。

理论上，任意次请求只要在数据状态更新之前都完成了查询操作，则业务逻辑的重复处理就会发生。如下图所示。优化的方向是减少查询到更新之间业务处理时间，可降低空档期的并发影响。极致情况下如果查询和更新变成了原子操作，则就不存在我们当前的问题。

防订单重复提交策略方法 - 文章图片

（2）基于缓存数据状态的验证

Redis存储查询轻量快速。在request进来的时候，可以先记录在缓存中。后续进来的request每次进行验证。整个流程处理完成，清除缓存。以退款为例子：

  • I. 每次退款发起申请，读取缓存中是否有以orderId为key的值
  • II. 没有，则往缓存中写入以orderId为key的value
  • III.有，则说明有该订单的退款正在进行。
  • IV. 操作完清缓存，或者缓存存值的时候设置生命周期

与1）的发放相比，数据库换成响应更快的缓存。但是仍然不是原子操作。插入和读取缓存还是有时间间隔。在极致的情况下还是存在重复操作的情况。此方法优化后，每周1笔重复操作。

防订单重复提交策略方法 - 文章图片

（3）利用唯一索引机制的验证

需要原子性操作，想到了数据库的唯一索引。新建一个TradeLock表：

CREATE TABLE `TradeLock` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`type` int(11) NOT NULL COMMENT '锁类型',
`lockId` int(11) NOT NULL DEFAULT '0' COMMENT '业务ID',
`status` int(11) NOT NULL DEFAULT '0' COMMENT '锁状态',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='Trade锁机制';

● 每次request进来则往表里面插入数据：

成功，则可以继续操作（相当于获取锁）；
失败，则说明有操作在进行。

● 操作完成后，删除此条记录。（相当于释放锁）。

目前已经上线，等待下周的数据统计。

防订单重复提交策略方法 - 文章图片

（4）基于缓存的计数器验证

由于数据库的操作比较消耗性能，了解到redis的计数器也是原子性操作。果断采用计数器。既可以提高性能，还不用存储，而且能提升qps的峰值。

还是以订单退款为例子：

● 每次request进来则新建一个以orderId为key的计数器，然后＋1。

如果>1（不能获得锁）: 说明有操作在进行，删除。
如果=1（获得锁）: 可以操作。

● 操作结束（删除锁）：删除这个计数器。

要了解计数器，可以参考：http://www.redis.cn/commands/incr.html

防订单重复提交策略方法 - 文章图片

总结：

PHP语言自身没有提供进程互斥和锁定机制。因此才有了我们上面的尝试。网上也有文件锁机制，但是考虑到我们的分布式部署，建议还是用缓存。在大并发的情况下，程序各种情况的发生。特别是涉及到金额操作，不能有一分一毫的差距。所以在大并发要互斥的情况下可以考虑3、4两种方案。

爱迪生尝试了1600多种材料选择了钨丝发明了灯泡，实践出真知。遇到问题，和问题斗争，最后解决问题是一个最大提升自我的过程，不但加宽自己的知识广度，更加深了自己的技能深度。达到目标之后的成就感更是不言而喻。

以上就是防订单重复提交策略方法的详细内容。

内容总结

以上是互联网集市为您收集整理的防订单重复提交策略方法全部内容，希望文章能够帮你解决防订单重复提交策略方法所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/274742.html

来源：【匿名】