订单唯一性(防止重复下单)方案
重复下单产生原因:
- 客户端原因:
比如下单的按键在点按之后,在没有收到服务器请求之前,按键的状态没有设为已禁用状态,还可以被按。又或者,在触摸屏下,用户手指的点按可能被手机操作系统识别为多次点击。
- 请求超时原因:
用户的设备与服务器之间可能是不稳定的网络。这样一个下单请求过去,返回不一定回得来。超时最大的问题是: 从用户的角度,他无法确定下单的请求是还没到服务器,还是已经到了服务器但是返回丢失了。——用户无法区分到底这个单下了还是没下。
- 用户各种无脑操作:
心急的用户可能会重启流程/重启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();//获取token
String 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%的拦截所有的可能性,必须依靠**技术+产品设计+运营支持**的综合手段才能解决这类问题。
此时就得依靠运营/客服的支持了。
****推荐使用方案四+方案五