前言

春节放假期间，一个项目上的积分接口被刷，而且不止一个人在刷，并且东西也被兑走，放假晚上被人叫起来排查问题，通过这个人的积分明细观察，基本一秒就能获取一次，远远超过了积分规则限定的次数，这肯定是用脚本了，虽然后期联系死活说自己是正常途径获取。由于是业主，我们还是决定自己来承担这个损失，被项目方从合同中扣除奖品费用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，另一方面测试的时候没有对接口进行并发测试，或者根本没有测出来，第三没有监控工具监控长事务，以及频繁请求。

作者《Prometheus+Grafana 实践派》专栏火热更新中

---

关注我，给你看更多精彩文章。