（1）什么是接口幂等性问题？
概念总结：由于网络延迟或者无响应状态影响了正常业务流程，导致客户端会发起多次重复请求，要求一次请求和多次请求的处理数据的结果要一致。
例子：
抖音点赞，一个用户在一条视频无论疯狂点击多少次，也只算一次点赞。
充值，由于网络延时或者无响应，未能返回充值成功结果，这个时候不允许用户重新支付该订单，不允许重复扣费。
退款业务，也是由于网络延时或者无响应，用户对一张订单的多次退款请求不允许重复退款。
（能够保证以上业务场景的正常处理，就需要接口具有幂等性）
（2）什么样的操作需要幂等性，什么样的操作不需要幂等性？
insert新增操作 / update更新操作，都不具备幂等性。多次请求可能会造成业务数据的错乱。
select查询操作 / delete删除操作，具备天然的幂等性。多次查询和多次删除同一条数据都不会对结果造成什么影响。
（3）常见的什么原因容易造成幂等性问题？
1:用户重复提交请求。快速重复点击，不断刷新提交数据页面提交数据。
2:多个项目，子系统模块之间的接口相互调用，为了防止网络抖动造成的请求丢失或者数据丢失，部分接口会设计成无响应状态或者响应超时对的时候进行自动重试。
3:MQ等消息队列中，重复消费问题。
（4）如何保证接口的幂等性？
1:通过业务处理逻辑的关键性数据判断。（例如退款申请表，生成对应商品和对应用户的订单号后，再次针对该商品的退款申请都将会找到已经存在的退款单处理进度返回，而不是简单的重新创建一个退款申请）
2:实时token验证。客户端的每一次的操作，都要携带着服务器给的随机token，token使用过后立马废弃删除，这样用户发起的多个请求，也只有第一个能执行处理，其他的在缓存中查询不出token之后，统一返回“请不要重复操作”之类的温馨提醒。
3:最基本的前端校验。防止用户重复点击，重复提交请求限制。
4:通过建立一张“操作表”来记录关键操作记录，如果存在就不执行。或者通过redis中的setnx做操作锁（一样是记录关键操作记录是否存在，返回boolean，更加便捷）