积分接口被刷爆，全体一个月降薪20%，这个项目我们遗漏了什么？

56 阅读 0 评论 37 点赞

我是靠谱客的博主完美蜜粉，最近开发中收集的这篇文章主要介绍积分接口被刷爆，全体一个月降薪20%，这个项目我们遗漏了什么？，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

前言

有一些往事总是会在酒后提起

我问朋友，在工作上有什么事情是到现在还记忆尤新的？

我朋友一个激灵坐起来，点上一支烟，只见烟头亮了4、5下，才见他吐出一口烟来，说道：“那还真有”

起因

刚参加工作那会做个积分兑换的项目，做完安安稳稳回家过年，哪知道才第三天，就被主管紧急召回，说是捅了大篓子，让我们快来。

回来了才知道项目被灰产盯上，积分被刷，业主业绩没做上去，东西倒是一箱箱往外兑，粗略估计，一天差不多损失上万。

我们赶紧排查，通过积分明细发现，这些人一秒就能获取一次积分，这远远超过了咱们规则的限定值，这肯定是用脚本了，我们后来联系上他，死活不承认。业主希望把负面影响减小到最大，选择不再追究，从我们的合同中扣。

那是我刚毕业做的第一个项目，上来就是项目人员全体降薪一个月，降20%！

俗话说，吃一堑长一智，所以我对这个事情印象还是蛮深的。

问题原因

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

–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());
  }
}

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

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();
    }
  }
}