前言

春节放假期间，一个项目上的积分接口被刷，而且不止一个人在刷，并且东西也被兑走，放假晚上被人叫起来排查问题，通过这个人的积分明细观察，基本一秒就能获取一次，远远超过了积分规则限定的次数，这肯定是用脚本了，虽然后期联系死活说自己是正常途径获取。由于是业主，我们还是决定自己来承担这个损失，被项目方从合同中扣除奖品费用1万余元。

问题原因

先说下接口的逻辑层次结构：

–controller 积分获取接口，用PointController表示

–service 积分获取接口service，用PointService表示

我用伪代码来表示整个调用逻辑：

PointController

@RestController
public class PointController {
          
   

	@Resource
	private PointService pointService;

	@GetMapping(/addPoint)
	public Response addPoint() {
          
   
		//分布式锁，使用redis的NX命令
		RedisDistributedLock lock = new RedisDistributedLock();
    //创建一个3s过期，100ms休眠的锁
		if(lock.lock("POINT_KEY", 3000L, 100L)) {
          
   
			try {
          
   
        //调用
				pointService.addPoint();
			} catch (Exception ex) {
          
   
				e.printStackTrace;
			} finally {
          
   
        //解锁
				lock.unlock("POINT_KEY");
			}
		}
		return Response.ok(getLastPoint());
	}
}

1. 创建一个分布式锁对象，该分布式锁使用redis的NX命令实现
2. 随后创建一个3s过期的分布式锁，以便锁住该新增积分的请求
3. 最后在新增积分执行完后，在finally中释放锁
4. 最后返回该用户的最终积分

PointService

public class PointService {
          
   
  
  @Transactional(rollbackFor = Exception.class)
  public void addPoint() {
          
   
    //查询积分规则
    PointRule pointRule = getPointRule();
    //查询用户该积分项的积分获取记录总数
    Integer total = getPointRecords();
    //判断该用户的积分记录总数是否大于 积分规则限定的次数
    //大于则不处理，返回
    if(total - pointRule.getRuleTimes >= 0) {
          
   
      return;
    }
    
    //生成积分记录
    int insert = insertPointRecords();
    //更新用户总积分
    if(insert > 0) {
          
   
      updateUserPoint();
    }
  }
}

PointService 中的添加积分逻辑：

1. 首先查询该项目积分规则，查询用户该积分项的积分获取记录总数
2. 判断该用户的积分记录总数是否大于 积分规则限定的次数，大于则不处理，返回
3. 生成积分记录
4. 更新用户总积分

该添加积分的逻辑整体上看好像没什么问题，也确实在一切正常的情况下运行是不会有问题的。

如果PointService 中的添加积分逻辑在分布式锁有效期3s内执行完，是不会有问题的。

但如果PointService中的添加积分逻辑超过3s…那是不是后续请求又可以获取锁了，这也正是这次事故的原因。

因为PointService中的添加积分逻辑超过了3s，并且上一个请求的事务还未提交，后续请求已经获取锁进入PointService，在查询积分记录后，判断还是满足规则，继续执行后续的逻辑，造成用户能够获取多次积分。

问题处理

原因总结一下：

1. 添加积分逻辑处理时间过长
2. 分布式锁超时

第一个问题：逻辑改动过大，需要时间调整，没有采用

第二个问题：换成Redisson，因为redisson在即使超时的情况下也会续锁，避免锁超时

总结

一方面因为忙于做项目，忽略了代码Review，另一方面测试的时候没有对接口进行并发测试，或者根本没有测出来，第三没有监控工具监控长事务，以及频繁请求。

Spring Boot Admin 系列