当前位置: 首页 > news >正文

生成订单幂等性(防止订单重复提交)

订单唯一性(防止重复下单)方案

重复下单产生原因:

  1. 客户端原因

比如下单的按键在点按之后,在没有收到服务器请求之前,按键的状态没有设为已禁用状态,还可以被按。又或者,在触摸屏下,用户手指的点按可能被手机操作系统识别为多次点击。

  1. 请求超时原因

用户的设备与服务器之间可能是不稳定的网络。这样一个下单请求过去,返回不一定回得来。超时最大的问题是: 从用户的角度,他无法确定下单的请求是还没到服务器,还是已经到了服务器但是返回丢失了。——用户无法区分到底这个单下了还是没下

  1. 用户各种无脑操作

心急的用户可能会重启流程/重启App/重启手机。在这种强制的手段下,任何技术手段都会失效。

解决方案:

方案一:提交订单按钮置灰

防止用户提交,最常规的做法,就是客户端点击下单之后,在收到服务端响应之前,按钮置灰。

前端页面直接防止用户重复提交表单,但网络错误会导致重传,很多RPC框架、网关都有自动重试机制,所以重复请求在前端侧无法完全避免。

当然,这种方案也不是真的没有价值。

这种方案可以在高并发场景下,从浏览器端去拦住一部分请求,减少后端服务器的处理压力,达到过滤流量的效果。

优点:简单。基本可以防止重复点击提交按钮造成的重复提交问题。

缺点:前进后退操作,或者F5刷新页面等问题并不能得到解决。

方案二:请求唯一ID+数据库唯一索引约束

需要客户端在请求下单接口的时候,需要生成一个唯一的请求号:requestId,服务端拿这个请求号,判断是否重复请求。实现的逻辑,流程如下:

当用户进入订单提交界面的时候,调用后端获取请求唯一ID,并将唯一ID值埋点在页面里面。

当用户点击提交按钮时,后端检查这个唯一ID是否用过,如果没有用过,继续后续逻辑;如果用过,就提示重复提交。

最关键的一步操作,就是把这个唯一ID 存入业务表中,同时设置这个字段为唯一索引类型,从数据库层面做防止重复提交。

优点:对于下单流量不算高的系统,可以采用这种 请求唯一ID + 数据表增加唯一索引约束`的方式,来防止接口重复提交!

缺点:并发量太低,10wqps高并发, 这个根本没法满足。

方案三:reids分布式锁+请求唯一ID

随着业务的快速增长,每一秒的下单请求次数,可能从几十上升到几百甚至几万。

面对这种下单流量越来越高的场景,此时数据库的访问压力会急剧上升,数据库会成为整个下单流程的瓶颈。

对于这样的场景,我们可以选择引入缓存中间件来缓解数据库高并发场景下的压力,实现的逻辑,流程如下:

当用户进入订单提交界面的时候,调用后端获取请求唯一 ID,同时后端将请求唯一ID存储到redis中再返回给前端,前端将唯一 ID 值埋点在页面里面。

当用户点击提交按钮时,后端检查这个请求唯一 ID 是否存在,如果不存在,提示错误信息;如果存在,继续后续检查流程。

使用redis的分布式锁服务,对请求 ID 在限定的时间内进行加锁,如果加锁成功,继续后续流程;如果加锁失败,提示说明:服务正在处理,请勿重复提交。

最后一步,如果加锁成功后,需要将锁手动释放掉,以免再次请求时,提示同样的信息;同时如果任务执行成功,需要将redis中的请求唯一 ID 清理掉。

优点:可以满足 10wqps高并发要求。

缺点:每次提交订单的时候,都需要调用服务端获取请求唯一ID

方案四:redis分布式锁+token:

创建订单的时候,用订单信息计算一个哈希值,去生成token ,大致 流程如下:

用户点击提交按钮,服务端接受到请求后,通过规则计算出本次请求唯一ID值

使用redis的分布式锁服务,对请求 ID 在限定的时间内尝试进行加锁,如果加锁成功,继续后续流程;如果加锁失败,说明服务正在处理,请勿重复提交。

最后一步,如果加锁成功后,需要将锁手动释放掉,以免再次请求时,提示同样的信息。

优点减少一次客户端与服务端之间的交互次数,提高下单流程效率

用订单信息计算一个哈希值生成token
    /*** 提交订单*/@PostMapping("/add")public Result add(@RequestBody OrdersVO ordersVO) {StpUtil.checkRoleOr("admin", "user");int hashKey = ordersVO.hashCode();//获取tokenString key = LOCK_KEY + hashKey;//获取锁Boolean isLock = redisTemplate.opsForValue().setIfAbsent(key, hashKey, 60, TimeUnit.SECONDS);if (!isLock) {//未获取到锁 说明订单重复提交 返回错误信息return Result.fail(ShopMsgConstant.REPEAT_SUBMIT.getCode(),ShopMsgConstant.REPEAT_SUBMIT.getMsg());}try {log.info("--------------获取锁成功,生成订单------------------");return goodsOrderService.add(ordersVO);} finally {if (hashKey == (int)redisTemplate.opsForValue().get(key) ){log.info("--------------释放锁------------------");redisTemplate.delete(key);}}}

方案五:技术+产品+运营支持

如果经过上述方案处理,还是会有用户误操作,直到收到两份商品才发现下重了。

在实际设计中,无论多么好的技术,也不可能100%的拦截所有的可能性,必须依靠**技术+产品设计+运营支持**的综合手段才能解决这类问题。

此时就得依靠运营/客服的支持了。

****推荐使用方案四+方案五

http://www.lryc.cn/news/416973.html

相关文章:

  • IDEA自定义注释模版
  • Spring Cloud Gateway实现API访问频率限制
  • 单例模式:确保唯一实例的设计模式
  • MCU调试技巧-串口打印
  • VS+Qt+C++点云PCL三维显示编辑系统
  • 代码随想录算法训练营第七天(一)| 454.四数相加II 383. 赎金信
  • SpringBoot+Mybatis 分页
  • 学习进行到了第十七天(2024.8.5)
  • 【Nuxt】Layout 布局和渲染模式
  • C:指针学习(1)-学习笔记
  • 【LVS】负载均衡之NAT模式
  • ASP.NET Core 基础 - 入门实例
  • 机器人主板维修|ABB机械手主板元器件故障
  • 大数据Flink(一百零六):什么是阿里云实时计算Flink版
  • ERCOT中的专业术语解释
  • Python酷库之旅-第三方库Pandas(069)
  • 基于hutools的国密SM2、3、4
  • 进程的等待(非阻塞轮询+阻塞)和替换控制详解
  • 24/8/6算法笔记 支持向量机
  • 测试用例等级划分
  • 打造Perl编译器前端:自定义语言处理的魔法
  • Visual Studio 和 Visual Studio Code 的比较与应用偏向
  • Python打开JSON/CSV文件的正确方式(针对UnicodeDecodeError)
  • 深入解析TikTok广告开户白名单:规范与申请指南
  • CSS技巧专栏:一日一例 19 -纯CSS实现超酷的水晶按钮特效
  • ArcGIS基础:基于数据图框实现地理坐标系下不同投影转换的可视化效果
  • ⚡4. Kubernetes核心资源管理操作实战
  • 【Wireshark 抓 CAN 总线】Wireshark 抓取 CAN 总线数据的实现思路
  • Linux网络编程3
  • gitlab 服务器安装