如何保证幂等性

一、背景：

分布式场景下，接口的开发大都需要保证幂等性。

幂等性：一个接口被调用，不管几次，产生一样的效果，一样返回结果。

接口调用过程中，很可能因为网络等原因进行重试调用，如果不能保证幂等性，那就完犊子了。

例如：用户支付的接口，用户有可能连续点击支付，总不能扣好几次钱吧。

二、场景：

1、前端重复提交：

用户快速重复点击多次，造成后端生成多个内容重复的数据。

2、接口超时重试：

对于给第三方调用的接口，为了防止网络抖动或其他原因造成请求丢失，这样的接口一般都会设计成超时重试多次。

HTTP,RPC等在超时的情况下会有重试机制。

3、消息重复消费：

MQ消息中间件，消息重复消费。

三、幂等性方案：

幂等性的保证，很明显无法通过一个方案解决所有问题，只能具体场景具体分析的。

1、业务表唯一索引：

对于数据插入的场景来说，这是最常见的方案。

核心业务字段设置为唯一索引，多次插入就会报错，从而保证幂等性。

2、状态流转控制：

状态流转也是最常见的幂等性保证手段。

如配送业务中，骑手的操作肯定会对业务流转状态进行校验。如果骑手已经提货，那就肯定不能再次提货的。

3、乐观锁版本号：

在业务表中新建一个字段version，int类型。

服务A调用服务B需要更新的时候，需要提前查询到version，然后作为参数传过去。

如果数据更新的时候将version + 1，接口如果发生重试的时候，version已经发生变更，那么也能保证幂等性。

PS：老实说，这个方案我本人没用过，有点麻烦。大部分的更新不需要保证幂等性，最终的数据也能保证一致。

4、去重：

对于前端调用的接口，有些场景无法通过前面的方案保证幂等性。

接口中可以新增一个参数，这个参数保证每次请求都是唯一的。

然后将这个参数保存，每次请求的入参校验都会查询这个参数是否存在，如果存在就返回。

参数保存的方案可以是MySQL或者Redis。

对于本身并发较低的场景，不会对MySQL服务造成压力，可以直接使用MySQL。否则，就要考虑Redis了，Redis这个key设置超时时间不用太长。

5、分布式锁：

考虑到分布式环境下，很多方案的校验如果无法保证串行的情况下，还是无法保证幂等性的。

例如，前面的状态机校验，并发环境下，可能还是会有问题，所以具体场景再进行分析。