概念：其任意多次执行所产生的影响均与一次执行的影响相同。
重复的场景包括：
前端重复提交：提交订单，用户快速重复点击多次，造成后端生成多个内容重复的订单。
接口超时重试：对于给第三方调用的接口，为了防止网络抖动或其他原因造成请求丢失，这样的接口一般都会设计成超时重试多次。
消息重复消费：MQ消息中间件，消息重复消费
幂等性
实现方式
1、Token机制
服务端提供了发送token的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取token，服务器会把token保存到redis中。（微服务肯定是分布式了，如果单机就适用jvm缓存）。
然后调用业务接口请求时，把token携带过去，一般放在请求头部。
服务器判断token是否存在redis中，存在表示第一次请求，可以继续执行业务，执行业务完成后，最后需要把redis中的token删除。
如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不被重复执行。
2、数据库去重表
往去重表里插入数据的时候，利用数据库的唯一索引特性，保证唯一的逻辑。唯一序列号可以是一个字段，例如订单的订单号，也可以是多字段的唯一性组合。
3、Redis实现
Redis实现的方式就是将唯一序列号作为Key，唯一序列号的生成方式和上面介绍的防重表的一样，value可以是你想填的任何信息。唯一序列号也可以是一个字段，例如订单的订单号，也可以是多字段的唯一性组合。当然这里需要设置一个 key 的过期时间，否则 Redis 中会存在过多的 key。具体校验流程如下图所示，实现代码也很简单这里就不写了。
4、多版本控制
多版本并发控制，乐观锁的一种实现，在数据更新时需要去比较持有数据的版本号，版本号不一致的操作无法成功。
幂等性测试
（1）需要更多的关注业务性质和产品设计上，是否需要做到幂等，是时间维度的幂等还是空间维度的幂等；
（2）接口的幂等测试一定不能遗漏，由于幂等场景相对容易制造出来，幂等测试的难度远远小于并发测试，因此在做接口测试时不妨对每个接口都思考一下是否需要幂等，需要的话就测试一下其幂等性；
（3）业务场景，特别是涉及到资金流动的业务场景，对失败重试机制一定要慎重；
（4）前端幂等测试，注意按钮的多次快速点击；
（5）后端幂等测试，就是接口的幂等测试，使用postman或jmeter多次发送同一参数的请求，查看服务端响应。
网友评论