如何保证接口的幂等性
为什么会产生接口幂等性问题
在计算机网络中，可能会遇到网络抖动、临时故障，或者服务调用失败，尤其是分布式系统中，接口调用失败更为常见。为了保证服务完整性，我们一般会发起接口重试调用，除了天然幂等的查询类接口不需要幂等处理以外，增删改类接口如果不处理幂等可能会对系统造成很大影响，因此接口的幂等设计尤为重要。
对于业务中需要考虑幂等的地方一般都是接口的重复请求，重复请求是指同一个请求因为某些原因被多次提交。导致这种情况的发生一般有以下几种常见的场景：
前端重复提交：用于在表单提交时由于网络波动没有及时作出提交成功响应，导致用户主观任务没有提交成功，然后重复点击提交。
接口超时重试：第三方调用接口时，由于超时等异常情况造成请求失败，都会添加重试机制，导致一个请求提交多次。
消息重复消费：当使用MQ消息中间件时，如果发生消息中间件出现错误未及时提交消息，导致发生重复消费。
幂等性解决方案
方案一：前端控制
针对第一种场景下既然是用户重复提交导致的，那我们可以想办法让用户没法重复提交。在前端做拦截，比如当按钮点击一次后置灰或者隐藏。但是前端往往并不可靠，还是得后端处理才更放心。
方案二：Token机制
逻辑就是：用户进入表单页面首先调用后端获取Token，后端返回Token并存入Redis，当用户提交表单时将Token也作为入参，后端先删除Redis中的Token，删除成功则保存表单数据，失败则提示用户重复。
这里为什么不限判断Redis中是否有这个Token再删除？是因为要保证操作的原子性，极端情况下，第一个请求查询到Redis中存在这个Token还没来得及删除，第二个请求过来也查询到这个Token，那么还是会造成重复提交的问题。
Token机制需要先请求后期Token的接口，在有些情况下明显并不合适。我们大部分请求都是要落到数据库，所以我们可以从数据库着手。
方案三：唯一索引
这种方案很好理解，使用唯一索引避免脏数据的添加，当重复数据落到数据库时抛出异常，保证数据的唯一性，唯一索引可以支持插入、更新、删除业务操作。
具体流程步骤：
建立一张去重表，其中某个字段建议唯一索引
客户端去请求服务端，服务器会将这次请求的一些信息插入去重表
由于表中某个字段是唯一索引，如果插入成功则表明表中没有这次请求信息执行后续逻辑，如果失败则代表重复请求
方案四：悲观锁
这里说的悲观锁是基于数据库层面，在获取数据时枷锁，党统十多个重复请求时，其他请求都无法进行操作，悲观锁只适用于更新操作。
例如：
select name from t_goods where id =1 for update;值得注意的是：上面的id字段一定要是主键或者唯一索引，不然行锁就会变成表锁。悲观锁使用时一般配合事务一起使用，数据锁定时间可能会很长，根据实际情况选用。
当然，除了数据库层面，悲观锁的实现还可用Redis等缓存锁、Zookeeper锁
在请求量比较大的情况下，使用悲观锁明显不合适，这时候就到乐观锁上场了。
方案五：乐观锁
可以通过版本号实现，为表增加一个version字段，当数据需要更新时，先去数据库获取此时的version版本号：
select version from t_goods where id =1;更新数据时首先要对比版本号，不想当说明已经有其他数据区更新数据了，提示更新失败。
update t_goods set count = count+1,version = version+1 wehre version = #{version};还有一种是通过状态机制实现，其实也是乐观锁。这种方法适合在有状态流转的情况下，比如订单的创建和付款，创建肯定先于付款，这是可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来实现幂等性。
update t_goods set status = #{status} wehre id=1 and status < #{status};同样，乐观锁也只适用于更新操作。
方案六：分布式锁
除了数据库层面的业务操作，有时候还有发短信、消息推送等操作，那数据库层面的锁就不合适了。这时候就要考虑代码层面的锁，而Java自带的锁只适用于单机环境，风不是集群部署情况下并不适用，这时候就可以采用分布式锁来实现（Redis或者Zookeeper）。
拿Redis分布式锁举例，比如一个订单发起支付请求，支付系统会去Redis换成中查询该订单的key，如果不存在则以key为订单号写入Redis。查询订单是否已支付，如果没有则进行支付，支付完成后删除该订单号对应的key。通过Redis做到了分布式锁，只有这次订单支付请求完成，下次请求才能进来。当然，一般key要设置过期时间，发生异常时要删除key。
下一篇写一下如何实现分布式锁。