什么情况会发生幂等性问题
编写创建Token和验证Token的接口以及实现类
@Service
public interface TokenService {
public Response createToken();
public Response checkToken(HttpServletRequest request);
}
比如在支付场景中，用户A的账号余额有150元，想转出100元，正常情况下用户A的余额只剩50元。一般情况下，sql是这样的：
有时我们在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样。我们在项目中为了解决接口超时问题，通常会引入了重试机制。第一次请求接口超时了，请求方没能及时获取返回结果，为了避免返回错误的结果，于是会对该请求重试几次，这样也会产生重复的数据。MQ消费者在读取消息时，有时候会读取到重复消息，如果处理不好，也会产生重复的数据。
具体实现步骤
幂等的本质是分布式锁的问题，分布式锁正常可以通过redis或zookeeper实现；在分布式环境下，锁定全局唯一资源，使请求串行化，实际表现为互斥锁，防止重复，解决幂等。
| Redis | Zookeeper | |
| 实现 | 简单 | 稍微复杂点 |
| 可靠性 | 低(锁可能无法释放) | 高，锁会自动释放，不会死锁 |
| 性能 | Redis 在没抢占到锁的情况下一般会去自旋获取锁，比较浪费性能(自选的期间干不了其他什么事情) | ZK 是通过注册监听器的方式获取锁，性能而言优于 Redis。 |
更新数据时首先和版本号作对比，如果不相等说明已经有其他的请求去更新数据了，提示更新失败。
首先引入需要的依赖：
org.springframework.boot
spring-boot-starter-data-redis
org.apache.commons
commons-lang3
最新版本
org.springframework.boot
spring-boot-starter-web
针对这种情况，我们可以通过建防重表来解决问题。
下面是Redis+Token机制流程：
唯一索引
后面有相同的请求过来，再执行相同的sql时，由于订单状态变成了再用status=2作为条件，无法查询出需要更新的数据，所以最终sql执行结果的影响行数是0，即不会真正的更新数据。但为了保证接口幂等性，影响行数是0时，接口也可以直接返回成功。
接口拦截器
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 {
}
}
幂等性的解决方案
很多时候业务表是有状态的，比如订单表中有：1-下单、2-已支付、3-完成、4-撤销等状态。如果这些状态的值是有规律的，按照业务节点正好是从小到大，我们就能通过它来保证接口的幂等性。
状态机
第一次请求时，该订单的状态是已支付，值是所以该update语句可以正常更新数据，sql执行结果的影响行数是订单状态变成了
token机制
如果出现多次相同的请求，可能会导致用户A的余额变成负数。这是很严重的系统bug。
该表可以只包含两个字段：id和唯一索引，唯一索引可以是多个字段比如：name、code等组合起来的唯一标识，例如：susan_000
配置自定义注解
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface ApiIdempotent {
}
最后是controller
幂等性:任意多次执行所产生的影响均与一次执行的影响相同幂等性用在接口上可以理解为：同一个接口，多次发出同一个请求，必须保证操作只执行一次。调用接口发生异常并且重复尝试时，总是会造成系统无法承受的损失，所以必须阻止这种现象的发生。
具体实现类，核心的业务逻辑都写在注释中了
@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);
}
}
假如id=123的订单状态是已支付，现在要变成完成状态。
乐观锁
需要特别注意的是：如果使用的是mysql数据库，存储引擎必须用innodb，因为它才支持事务。此外，这里id字段一定要是主键或者唯一索引，不然会锁住整张表。
乐观锁可以实现的往往用悲观锁也能实现，在获取数据时进行加锁，当同时有多个重复请求时其他请求都无法进行操作。
这里的乐观锁指的是用乐观锁的原理去实现，为数据字段增加一个version字段，当数据需要更新时，先去数据库里获取此时的version版本号
这些都是幂等性问题。
分布式锁
使用唯一索引可以避免脏数据的添加，当插入重复数据时数据库会抛异常，保证了数据的唯一性。在表中加唯一索引，这是一个非常简单，并且有效的方案。
建防重表
幂等性的解决方案有很多，本文主要讲Redis+Token保证接口幂等性
悲观锁
有时候表中并非所有的场景都不允许产生重复的数据，只有某些特定场景才不允许。这时候，直接在表中加唯一索引，显然是不太合适的。
如果是java程序需要捕获：DuplicateKeyException异常，如果使用了spring框架还需要捕获：MySQLIntegrityConstraintViolationException异常。
为了解决这个问题，可以加悲观锁，将用户A的那行数据锁住，在同一时刻只允许一个请求获得锁，更新数据，其他的请求则等待。
token机制的核心思想是为每一次操作生成一个唯一性的凭证，也就是token。一个token在操作的每一个阶段只有一次执行权，一旦执行成功则保存执行结果。对重复的请求，返回同一个结果。token机制的应用十分广泛。
比如下面这些情况，如果没有实现接口幂等性会有很严重的后果：支付接口，重复支付会导致多次扣钱订单接口，同一个订单可能会多次创建。
文章为作者独立观点，不代表股票交易接口观点
相关文章
股民评论