如果保证接口的幂等性

前言

大家好，我是一只笨拙还坚持努力看源码的小蜗牛。今天的主题是接口的幂等性，如果你从没了解过，那么你现在面部表情肯定跟我当初看到这个名词的一样，然后心里大骂一声，什么鬼？那么今天，我来解释下这个鬼玩意到底是什么。

接口的幂等性

幂等性原本是数学上的概念，即公式：f(x) = f(f(x)) 能够成立的数学性质
那么在编程领域，为对一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。
幂等性是分布式系统设计中非常重要的概念，具有这一性质的接口在设计时总是秉持这样的一种理念：调用接口发生异常并且重复尝试时，总是会造成系统无法承受的损失，所以必须阻止这种现象的发生。

为何要保证接口的幂等性

试想一下这样的一种场景：在电商平台上支付后，因为网络原因导致系统提示你支付失败，于是你又重新付款了一次，等完成后发现你的网银上被扣款了两次，这是一种什么样的体验。

造成上述问题的原因可能很多，例如第一次付款的时候实际支付后，后台已经发生了扣款，但是因为网络的原因，导致系统的误判。又比如第一次付款确实失败了，第二次付款重复发送了两次，导致了两次扣款。

幂等性就是解决这类问题的方案之一。在电商，银行，金融公司对数据的准确性和一致性要去很高，所以这一特性具有十分重要的地位。

幂等性的常见思路

1，乐观锁
在数据更新的时候，先去查询数据的版本号，如果版本号一致才允许更新，否则操作无法成功。这是高并发的时候效率高的一种锁机制。
2，建立唯一索引
在表中给一个字段或者时两个字段组合建立唯一索引，当第一次插入数据成功以后，以后重复的请求，插入数据永远无法成功。
3，TOKEN机制
这种机制就比较重要了，适用的范围也比较广，实现的方式也比较多。
核心思路就是，为每一次操作加一个token验证，验证通过则处理，处理完了删除token。当重复请求过来，就无法通过token的验证了。

比如，支付订单之前我先发起一次请求到后台去申请token，然后存放到redis中。然后我真正发起支付请求，我先去验证该请求的token是否存在，如果存在则继续操作。如果不存在，就可以判断是重复请求。

好了，今天的分享就此结束，感谢！