什么是幂等性？
幂等性:任意多次执行所产生的影响均与一次执行的影响相同
幂等性用在接口上可以理解为：同一个接口，多次发出同一个请求，必须保证操作只执行一次。
调用接口发生异常并且重复尝试时，总是会造成系统无法承受的损失，所以必须阻止这种现象的发生。
比如下面这些情况，如果没有实现接口幂等性会有很严重的后果：
支付接口，重复支付会导致多次扣钱
订单接口，同一个订单可能会多次创建。
什么情况会发生幂等性问题
- 有时我们在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样。
- 我们在项目中为了解决接口超时问题，通常会引入了重试机制。第一次请求接口超时了，请求方没能及时获取返回结果（此时有可能已经成功了），为了避免返回错误的结果，于是会对该请求重试几次，这样也会产生重复的数据。
- MQ消费者在读取消息时，有时候会读取到重复消息，如果处理不好，也会产生重复的数据。
这些都是幂等性问题。
幂等性的解决方案
幂等性的解决方案有很多，本文主要讲Redis+Token保证接口幂等性
唯一索引
使用唯一索引可以避免脏数据的添加，当插入重复数据时数据库会抛异常，保证了数据的唯一性。
在表中加唯一索引，这是一个非常简单，并且有效的方案。
alter table `order` add UNIQUE KEY `un_code` (`code`);
如果是java程序需要捕获：DuplicateKeyException异常，如果使用了spring框架还需要捕获：MySQLIntegrityConstraintViolationException异常。
乐观锁
这里的乐观锁指的是用乐观锁的原理去实现，为数据字段增加一个version字段，当数据需要更新时，先去数据库里获取此时的version版本号
select version from tablename where xxx
更新数据时首先和版本号作对比，如果不相等说明已经有其他的请求去更新数据了，提示更新失败。
update tablename set count=count+1,version=version+1 where version=#{version}
悲观锁
乐观锁可以实现的往往用悲观锁也能实现，在获取数据时进行加锁，当同时有多个重复请求时其他请求都无法进行操作。
比如在支付场景中，用户A的账号余额有150元，想转出100元，正常情况下用户A的余额只剩50元。一般情况下，sql是这样的：
update user amount = amount-100 where id=123;
如果出现多次相同的请求，可能会导致用户A的余额变成负数。这是很严重的系统bug。
为了解决这个问题，可以加悲观锁，将用户A的那行数据锁住，在同一时刻只允许一个请求获得锁，更新数据，其他的请求则等待。
select * from user id=123 for update;
需要特别注意的是：如果使用的是mysql数据库，存储引擎必须用innodb，因为它才支持事务。此外，这里id字段一定要是主键或者唯一索引，不然会锁住整张表。
建防重表
有时候表中并非所有的场景都不允许产生重复的数据，只有某些特定场景才不允许。这时候，直接在表中加唯一索引，显然是不太合适的。
针对这种情况，我们可以通过建防重表来解决问题。
该表可以只包含两个字段：id 和 唯一索引，唯一索引可以是多个字段比如：name、code等组合起来的唯一标识，例如：susan_0001。
分布式锁
幂等的本质是分布式锁的问题，分布式锁正常可以通过redis或zookeeper实现；在分布式环境下，锁定全局唯一资源，使请求串行化，实际表现为互斥锁，防止重复，解决幂等。
| Redis | Zookeeper | |
| 实现 | 简单 | 稍微复杂点 |
| 可靠性 | 低(锁可能无法释放) | 高，锁会自动释放，不会死锁 |
| 性能 | Redis 在没抢占到锁的情况下一般会去自旋获取锁，比较浪费性能(自选的期间干不了其他什么事情) | ZK 是通过注册监听器的方式获取锁，性能而言优于 Redis。 |
状态机
很多时候业务表是有状态的，比如订单表中有：1-下单、2-已支付、3-完成、4-撤销等状态。如果这些状态的值是有规律的，按照业务节点正好是从小到大，我们就能通过它来保证接口的幂等性。
假如id=123的订单状态是已支付，现在要变成完成状态。
update `order` set status=3 where id=123 and status=2;
第一次请求时，该订单的状态是已支付，值是2，所以该update语句可以正常更新数据，sql执行结果的影响行数是1，订单状态变成了3。
后面有相同的请求过来，再执行相同的sql时，由于订单状态变成了3，再用status=2作为条件，无法查询出需要更新的数据，所以最终sql执行结果的影响行数是0，即不会真正的更新数据。但为了保证接口幂等性，影响行数是0时，接口也可以直接返回成功。
token机制
token机制的核心思想是为每一次操作生成一个唯一性的凭证，也就是token。一个token在操作的每一个阶段只有一次执行权，一旦执行成功则保存执行结果。对重复的请求，返回同一个结果。token机制的应用十分广泛。
具体实现步骤
下面是Redis+Token机制流程图：
首先引入需要的依赖：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>最新版本</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>
编写创建Token和验证Token的接口以及实现类
@Service public interface TokenService { public Response createToken(); public Response checkToken(HttpServletRequest request); }
具体实现类，核心的业务逻辑都写在注释中了
@Service public class TokenServiceImpl implements TokenService { @Autowired private RedisTemplate redisTemplate; @Override public Response createToken() { //生成uuid当作token String token = UUID.randomUUID().toString().replaceAll("-",""); //将生成的token存入redis中 redisTemplate.opsForValue().set(token,token); //返回正确的结果信息 Response response=new Response(0,token.toString(),null); return response; } @Override public Response checkToken(HttpServletRequest request) { //从请求头中获取token String token=request.getHeader("token"); if (StringUtils.isBlank(token)){ //如果请求头token为空就从参数中获取 token=request.getParameter("token"); //如果都为空抛出参数异常的错误 if (StringUtils.isBlank(token)){ throw new ServiceException(ResponseCode.ILLEGAL_ARGUMENT.getCode().toString(),ResponseCode.ILLEGAL_ARGUMENT.getMsg()); } } //如果redis中不包含该token，说明token已经被删除了，抛出请求重复异常 if (!redisTemplate.hasKey(token)){ throw new ServiceException(ResponseCode.REPETITIVE_OPERATION.getCode().toString(),ResponseCode.REPETITIVE_OPERATION.getMsg()); } //删除token Boolean del=redisTemplate.delete(token); //如果删除不成功（已经被其他请求删除），抛出请求重复异常 if (!del){ throw new ServiceException(ResponseCode.REPETITIVE_OPERATION.getCode().toString(),ResponseCode.REPETITIVE_OPERATION.getMsg()); } return new Response(0,"校验成功",null); } }
配置自定义注解
@Target({ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) public @interface ApiIdempotent { }
接口拦截器
public class ApiIdempotentInterceptor implements HandlerInterceptor { @Autowired private TokenService tokenService; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } HandlerMethod handlerMethod= (HandlerMethod) handler; Method method=handlerMethod.getMethod(); ApiIdempotent methodAnnotation=method.getAnnotation(ApiIdempotent.class); if (methodAnnotation != null){ // 校验通过放行，校验不通过全局异常捕获后输出返回结果 tokenService.checkToken(request); } return true; } @Override public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception { } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { } }
配置拦截器以及redis
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(apiIdempotentInterceptor()); } @Bean public ApiIdempotentInterceptor apiIdempotentInterceptor() { return new ApiIdempotentInterceptor(); } }
最后是controller
@RestController @RequestMapping("/token") public class TokenController { @Autowired private TokenService tokenService; @GetMapping public Response token(){ return tokenService.createToken(); } @PostMapping("checktoken") public Response checktoken(HttpServletRequest request){ return tokenService.checkToken(request); } }
结果验证
首先通过token接口创建一个token出来，此时redis中也存在了该token
在jmeter中同时运行50个请求，我们可以观察到，只有第一个请求校验成功，后续的请求均提示请勿重复操作。
