介绍一下你们项目中的优惠券功能
项目中优惠券分为两类:
- 免费优惠券:是用户手动来领取。
- 兑换码优惠券:是给指定用户发访的,用户需要用指定的兑换码领取。
所有优惠券可以设置发访方式:
- 立刻发放:马上发放。
- 定时发放:通过
Redisson
的延迟队列完成。
也可以设置优惠券的使用限制:
- 固定天数:优惠券领取后的有效时间。
- 固定时间段:优惠券只能在固定时间段中使用。
同时也可以给优惠券的领取次数进行设置。
你们项目中是如何防止优惠券超领的
超领分为两类,分为:多人超领、单人超领
- 多人超领:在多线程的情况下运行,同时操作了共享资源,且不具备原子性,从而产生了超领现象
- 解决方案:
1、使用synchronized
锁定出问题的代码。锁的粒度大,性能差,在被锁定的代码又成为了单线程
2、使用CAS
乐观锁,更新数据前判断数据与之前查询到的是否一致,不一致则其它线程更新过。本次操作放弃或重试。
- 解决方案:
- 单人超领:单用户频繁点击领取,或者因为网络故障等情况发送了多次请求,导致查询的判断逻辑失效,而导致超领现象。
- 解决方案:
1、后端使用synchronized
对查询判断逻辑加锁,锁对象为用户id
。
2、分布式系统需要用到分布式锁。
3、前端设置防抖操作。
- 解决方案:
注意Long类型的id要保证精度不丢失,请用
userId.toString().intern()
做为锁对象。
事务失效的场景有哪些
@Transactional
失效的场景有以下几个:
- 非public修饰的方法。解决方法:改为
public
- 非事务方法调用事务方法。解决方法:添加
AspectJ
依赖,用其代理对象调用事务方法。 - 在事务中捕获异常。解决方法:在catch中手动抛出
Runtime
异常 - 抛出非运行时异常。解决方法:在
@Transactional
上设置rollbackFor
属性为最大异常.class
- 不适当的事务传播行为。解决方法:注意事务的传播行为