当前位置: 首页 > news >正文

因为锁的问题,我们被扣了1万

前言

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

  1. Grafana 的介绍和安装
  2. Grafana监控大屏配置参数介绍(一)
  3. Grafana监控大屏配置参数介绍(二)
  4. Grafana监控大屏可视化图表
  5. Grafana 查询数据和转换数据
  6. Grafana 告警模块介绍
  7. Grafana 告警接入飞书通知

Spring Boot Admin 系列

  1. Spring Boot Admin 参考指南
  2. SpringBoot Admin服务离线、不显示健康信息的问题
  3. Spring Boot Admin2 @EnableAdminServer的加载
  4. Spring Boot Admin2 AdminServerAutoConfiguration详解
  5. Spring Boot Admin2 实例状态监控详解
  6. Spring Boot Admin2 自定义JVM监控通知
  7. Spring Boot Admin2 自定义异常监控
  8. Spring Boot Admin 监控指标接入Grafana可视化

相关文章:

  • 当我尝试问了chatGPT几个问题之后,我感到了危机......
  • Spring 事务管理详解及使用
  • 第十四届蓝桥杯三月真题刷题训练——第 9 天
  • 【C语言】指针的深度理解(一)
  • python带你成功复刻热门手机游戏——飞翔的小鸟
  • Redis源码---整体架构
  • STM32之SPI
  • 课设-机器学习课设-实现新闻分类
  • 什么是刺猬理念
  • 软件测试用例篇(5)
  • 【CSS】快速入门笔记
  • 设计模式之不变模式
  • 【LeetCode】33. 搜索旋转排序数组、1290. 二进制链表转整数
  • HTTPS协议之SSL/TLS详解(下)
  • 2023金三银四常见Handler面试总结,附带答案
  • DML 添加、修改、删除数据
  • [ROC-RK3568-PC] [Firefly-Android] 10min带你了解I2C的使用
  • Shell编程:轻松掌握入门级Shell脚本,成为Shell高手
  • JavaScript 高级实例集合
  • 【Android -- 开源库】表格 SmartTable 的基本使用
  • 上海未来亚洲研究会第六届会员大会举行,叶青当选会长
  • 大家聊中国式现代化|彭羽:为国家试制度探新路,推进高水平对外开放
  • 岳阳一管道疑似有黑水直排东洞庭湖,生态环境局:已赶往现场核查
  • 对话地铁读书人|媒体人Echo:读书使人远离“班味”
  • 中国驻日本大使馆发言人就日方涉靖国神社消极动向答记者问
  • 广西人饮旱情仍持续发展,桂西北、桂中风险较高