【掘金】如何做一个防重设计

Scroll Down

前言

在业务设计中防重设计是一个关键点,已接口为例,防重就是防止接口被多次调用而产生脏数据,比如支付订单出现重复支付,所以说防重至关重要,在如何防虫之前我们首先看一下如何出现重复数据。

如何出现多次调用

多次调用接口的出现有主观原因比如:人为重复请求攻击,用户的误操作等;也有客观原因比如:为了健壮性进行超时重试;

  • 重复请求攻击

对于这种恶意攻击,其实已经属于安全范畴了,我们可以通过黑名单+限流来处理,下一步再考虑防重处理;

  • 用户的误操作

比如用户在界面点击提交按钮,因为手误出现多次点击提交,这种情况客户端可以做一些处理,减少用户的误操作,比如提交完按钮变灰等;当然提供方的防重处理也是必不可少的;

  • 超时重试

接口调用方为了保证系统的健壮性,往往会做一些重试处理,比如各种RPC框架都已经帮我们内置了容错机制,提供方需要做好防重;

如何做好防重处理,其实核心就是保证多个相同的请求只有一次被执行,或者说多次调用和一次调用产生的效果是一样的,也就是我们经常说的要保证幂等性;

何时需要防重

所有的操作说到底都是增删改查,其实我们真正需要做防重处理的,更重要的是增加和修改;查询和删除本身执行一次和多次,产生的效果是一样的,有天然幂等性,虽然说有天然幂等性,但是查询和删除本身也是要消耗资源的,如果能防止重复执行,也能节省资源;
增加和修改是必须要做防重的,增加可以以下单为例,修改可以以更新库存为例,如果没有做好防重后果是非常严重的;下面具体看看都有哪些防重的措施;

如何防重

上面说到主要是针对增加和修改需要做好防重处理,当然针对增加和修改其实是有不同的防重措施的,也有统一的方式。下面分别介绍:

统一防重

  • token机制

服务器需要提供获取token机制的服务,这样每次客户端请求的时候先获取token,服务器端会将token保存在redis中;客户端发送请求的时候会带上token,这样服务器端可以拿到token直接去redis中做删除处理,根据返回值判断是否成功:

localhost:0>get token
"111"
localhost:0>del token
"1"
localhost:0>del token
"0"

通过redis存放token,这样在分布式环境下也能很好的工作;

  • 防重key

根据请求参数生成md5密文,然后用此密文作为key存入redis中,可以通过使用setnx命令来保证只有一个能保存成功;

key = MD5.md5("param1="+param1+"&param2="+param2...)

localhost:0>setnx key 1
"1"
localhost:0>setnx key 1
"0"

  • 防重表

可以利用表的唯一索引约束,可以使用类似防重key作为唯一索引字段,多次请求过来只会有一个插入成功,为了防止防重表数据过多,可以启动一个定时器定期清理;

以上几张方式其实和具体业务关系不大,可以使用大部分场景;而且通过redis或者数据库,以及原子性操作来保证在分布式环境下也可以很好的运行;

插入防重

  • select+insert

插入数据最先想到的是先检查有没有,然后再插入,但是这样明显存在两个操作,不是原子性操作,单节点下还能通过锁来解决,分布式环境下就需要用分布式锁来保证原子性了;当然也可以结合其他方式一起使用,比如下面的唯一主键机制;

  • 唯一主键

这种方式其实就是不直接使用数据库自增主键了,使用分布式id算法生成,这样在插入数据时就可以通过唯一主键进行约束,保证只会有一条成功;

  • 回滚机制

有些业务其实是有正向流程和逆向流程的,比如订单支付,在接受到银行返回的支付成功通知时判断订单的状态,如果已经支付成功,可以直接走退款流程;

更新防重

  • 乐观锁

乐观锁常被用在更新场景中,比如下面通过版本号方式来实现:

update table_name
	sale = sale+1,
	version = version+1
where id = #{id}
and version =#{version]
  • 状态机乐观锁

在相关订单的业务中, 很多都会涉及到状态机,状态是流转的,有了上一个状态才会有下一个状态,比如常见的购物订单包括:提交未支付,支付成功,待发货,发货中,已签收,每个状态都需要前置状态;

 update table_name
	set status = 下一个状态
	where id=#{id} 
	and status=#{status}

防重的方法很多,我们往往需要更加自己的业务做相关的选择,不同的业务,不同的业务量,不同的容忍程度都会影响我们如何去做防重;每种方式也不是都是独立存在的,有时候往往需要多种方式整合起来。