数学中的幂等是指f(x) = f(f(x)),编程领域的术语是指同一个操作,在重复提交的情况下,最终产生的影响是不变的。举例说:
总结: 对于重要的接口,在实现接口时,一定要考虑是否具备幂等性。
既然不是所有的接口,那都有哪些场景的接口,会需要考虑幂等性呢?
比如上文说的支付回调接口,也包括在其他的异步操作下的对外接口。
你都必须考虑是否支持幂等。
举个例子,课程服务调用课堂服务的批量创建课堂接口,由于后者是异步的操作,所以待创建完成,课堂服务将要回调通知课程服务。
于是,课程服务需要开放一个接口出来,此接口就必须支持幂等。
有些业务,需要削峰填谷,会先把异步操作的消息给到Mq,然后在监听方法中消费该mq消息。这里举一个异步复制某文件夹及其下的所有文件为例。
当出现网络超时,需要重试的时候,你的接口是否支持幂等呢?
比如openfeign就很好地支持retry机制。
在进一步阐述如何实现幂等前,我们有必要搞清楚,哪些是天然幂等的。
都说自己每天写的代码都是CRUD,我们现在就来分析下它们是否幂等。
查询方法,都说查询的实现往往是最复杂的代码,幸好,它就是幂等的。虽然你前后的查询返回结果可能不一样,然而并不会影响服务端的分毫。
基于版本号或者状态机的更新操作,具体到sql语句,有两种写法,见下:
# 不建议的写法
update PayTrade t set t.status = :newStatus, t.outTradeNo = :outTradeNo, t.payOkDate = :payOkDate where t.channelTradeNo = :channelTradeNo
# 建议你这么写
update PayTrade t set t.status = :newStatus, t.outTradeNo = :outTradeNo, t.payOkDate = :payOkDate where t.channelTradeNo = :channelTradeNo and t.status = :oldStatus
他们的区别就是是否要求前一个状态,后面的sql多了一个“ t.status = :oldStatus ”
我们说,它就是一个幂等操作,而上面的写法则不建议,它不是幂等的。
这里举例了基于状态机的更新,基于版本号的类似,就不一一赘述了。
最后说一说CRUD的删除操作D,它也是天然幂等的。因为删除了的数据,第二次想要再删除而不得了。
大多数的新增操作,都需要最引起你的重视,极其容易导致重复操作。
可以是一个随机值token,也可以是业务上的一个字段。
前者是客户端根据约定生成的一个值,这个一般使用userId+时间戳,后者则是业务上的唯一值,比如订单号、课程编号等。
那么随机token,可不可以由服务端来颁发给客户端呢?
也行,原本一个接口就能完成的,拆分成了两个接口。(增加了一个颁发token的接口)
下文将详细说明,如果使用分布式锁实现接口的幂等。
订单服务接收支付服务的支付回调,先根据订单号查询订单详情,如果数据库返回支付流水号和回调接口中的入参支付流水号相同,则忽略该回调,不做任何后续操作。
下面展示一下其简略代码:
final Order order = orderRepository.findByNo(orderPaymentMarkRequest.getOrderNo());
// 如果流水号一样,认为曾经标记支付成功,保持幂等
if (!StringUtils.equals(order.getPayNo(), orderPaymentMarkRequest.getPayNo())) {
// 业务处理,更新订单等等
}
public class OrderPaymentMarkRequest {
@ApiModelProperty(notes = "订单号")
private String orderNo;
@ApiModelProperty(notes = "平台支付流水号")
private String payNo;
}
引入状态机或者版本号等机制,前文已有举例,这里不再重复。
代码示例:
@Lock(name = "CourseCenter", key = "'createLecture:token:'+ #request.token")
@Transactional(rollbackFor = Throwable.class)
public ApiResult createLecture(LectureCreateRequest request) {
if (log.isInfoEnabled()) {
log.info("创建讲次,入参是{}", JsonUtils.toJsonString(request));
}
// 其他操作
}
}
这里使用了自定义注解封装分布式锁,所以代码本身比较简单。
鉴于篇幅,具体实现分布式锁,网上也比较多的实现方案。
本文就不具体展开论述了。