接口幂等性问题

接口幂等性问题是指无论调用多少次同一个接口，产生的效果都是相同的。
在网络通信中，由于各种原因（网络延迟、请求重试等），可能导致接口被重复调用，而对于某些操作，重复执行可能会产生错误或者不一致的结果。
【1】token机制
通过token机制可以保证接口的幂等性。
具体实现方式如下：
在调用需要保证幂等性的接口之前，前端向后端请求生成一个随机的token，并将该token存储在Redis等中间存储服务中，并返回给前端。
后续调用接口时，前端将该token携带在请求头中。
服务器接收到请求后，判断该token是否存在于中间存储服务中
如果存在，则表示第一次请求，执行对应的业务逻辑并删除对应的token；
如果不存在，则表示重复操作，直接返回重复标识给前端。
通过这种方式，当重复请求发生时，服务器能够根据token的存在与否来判断是否执行业务逻辑，从而保证幂等性。
1、下单接口的前一个接口，只要一访问，后端生成一个随机字符串，存到redis中，把随机字符串返回给前端
2、然后调用业务接口请求时，把随机住非常携带过去，一般放在请求头部。
3、服务器判断随机住非常是否存在redis中，存在表示第一次请求，然后redis删除随机字符串,继续执行业务。
4、如果判断随机字符串不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不被重复执行
【2】乐观锁机制(更新的场景中)
乐观锁机制可以在更新场景中确保接口的幂等性。
具体实现方式如下：
在数据库操作（如更新）时，使用乐观锁可以保证接口的幂等性。
乐观锁通过在更新操作时判断数据的版本号，来避免多线程同时更新导致的数据不一致问题。
当多个请求同时修改同一条记录时，只有其中一个请求能够成功更新，其他请求需要重新获取最新数据再进行尝试。
update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 1
【3】唯一主键
利用数据库的主键唯一约束特性，可以解决在插入场景时的幂等问题。
如果要求主键是自增的，那么业务需要生成全局唯一的主键，确保重复插入时会遇到主键冲突而失败，从而保证幂等性。
这个机制是利用了数据库的主键唯一约束的特性，解决了在insert场景时幂等问题。
但主键的要求不是自增的主键，这样就需要业务生成全局唯一的主键
【4】唯一ID(unique)
在调用接口时，生成一个唯一ID，并将该ID保存在Redis等集合数据结构中。
每次调用接口时，先判断该唯一ID是否存在于集合中
如果存在则表示该请求已经处理过，直接返回结果；
如果不存在，则表示第一次请求，执行对应的业务逻辑并将唯一ID加入集合中。
通过这种方式，可以通过唯一ID的存在与否来判断是否执行业务逻辑，从而保证幂等性。
调用接口时，生成一个唯一id，redis将数据保存到集合中（去重），存在即处理过
【5】防重表
防重表的思想是在操作之前
先将唯一标识（如订单号）插入到一个专门的表中，将该唯一标识作为表的唯一索引。
然后，在进行实际的业务操作时，通过数据库的事务支持，保证业务表和防重表在同一个事务中。
这样，在重复请求发生时，由于唯一索引的约束，重复的请求会导致插入失败，从而避免了幂等问题的产生。
使用订单号orderNo做为去重表的唯一索引，把唯一索引插入去重表，再进行业务操作，且他们在同一个事务中。
这个保证了重复请求时，因为去重表有唯一约束，导致请求失败，避免了幂等问题。
这里要注意的是，去重表和业务表应该在同一库中，这样就保证了在同一个事务，即使业务操作失败了，也会把去重表的数据回滚。这个很好的保证了数据一致性。
【6】前端
在前端界面上，可以通过禁用按钮等方式来避免用户多次点击触发重复请求的问题。
一旦按钮被点击，就禁止再次点击，直到操作完成。
接口幂等性问题是指无论调用多少次同一个接口，产生的效果都是相同的。
在网络通信中，由于各种原因（网络延迟、请求重试等），可能导致接口被重复调用，而对于某些操作，重复执行可能会产生错误或者不一致的结果。