day7题目

1 介绍一下你们项目中的优惠券功能

优惠券功能涉及的微服务: 优惠劵微服务和用户微服务.

下面我分别从管理端和用户端介绍一下优惠券功能

管理端:

设置优惠劵: 可定义优惠券的类型、优惠金额、发放数量,每人限领数量.

发放优惠劵. 主要功能是:设置发放方式,设置优惠券的领用期限,设置优惠券的使用期限.

发放流程:

1. 验证优惠券是否存在.
2. 优惠券存在,但是必须是待发放和已暂停状态才可以发放.
3. 判断是否立即发放.立即发放则修改优惠券的发放状态为发放中,修改发放时间.
4. 定时发放则先修改优惠券的发放状态为未开始.定时发放通过延时任务实现.
5. 发放优惠券的时候，如果发现优惠券的领取方式是指定发放，则需要生成兑换码.

用户端:

1. 查询优惠劵. 用户在优惠劵界面可以查看
2. 领取优惠劵. 用户在优惠劵界面可以直接领取.
3. 兑换优惠劵. 通过兑换码兑换优惠劵.
4. 使用优惠劵.

兑换码特征：

1 可读性好：

长度不超过10个字符;

只能是24个大写字母和8个数字组成：ABCDEFGHJKLMNPQRSTUVWXYZ23456789

2 数据量大：优惠活动比较频繁，必须有充足的兑换码，最好有10亿以上的量

3 唯一性：10亿兑换码都必须唯一，不能重复，否则会出现兑换混乱的情况

4 不可重兑：兑换码必须便于校验兑换状态，避免重复兑换

5 防止爆刷：兑换码的规律性不能很明显，不能轻易被人猜测到其它兑换码

6 高效：兑换码生成、验证的算法必须保证效率，避免对数据库带来较大的压力

2 你们项目中是如何防止优惠券超领的

项目中优惠券超领情况有: 1 多人超领   2 单人超领, 针对不同超领情况有不同的解决方案.

多人超领.

产生原因: 判断库区和更新库存不具备原子性

在库存充足时多个线程同时进入,但是”更新优惠券的已领数量”操作,没有及时修改.(线程的权限是CPU随机分配的).

解决办法: 使用乐观锁解决问题, 让判断库区和更新库存具备原子性.(通过修改更新库存的sql语句解决)

1可以在数据表中加一个字段

2 sql语句本身具备原子性,所以保证 优惠劵可领取数量<优惠劵总数量 就可以解决问题.具体做法:更改”更新优惠券的已领数量”的sql语句.

单人超领

一,发生超领的原因: 

判断是否超出限领数量多个线程进入,但是”保存用户优惠券信息”操作没有及时执行.(两段代码不具备原子性)

二,解决办法

使用悲观锁, 将 "判断是否超出限领数量" 操作和 ”保存用户优惠券信息” 操作上锁.

3 事务失效的场景有哪些

事务失效的场景有以下几种: 

1. 事务方法非public修饰
2. 非事务方法调用事务方法
3. 事务方法的异常被捕获
4. 事务异常类型不对
5. 事务传播行为不对

       1 Spring的事务是基于AOP的方式结合动态代理来实现的。因此事务方法一定要是public的，这样才能便于被Spring做事务的代理和增强.(如果不是public,代理对象没有暴力反射,就无法获取到方法)

        4 Spring的事务管理默认处理的异常类型是RuntimeException，当事务方法内部抛出了一个IOException时，不会被Spring捕获，因此就不会触发事务回滚，事务就会失效.