说一下你负责的优惠券是如何实现的？

做这个优惠券是为了引流吗

优惠券功能包括两大部分:一个是管理端对于优惠券的管理和发放，另一方面是用户端优惠券的领取和使用。

首先是管理端对于优惠券的管理和发放：

优惠券新增之后并不会直接展示在用户端，而是在管理端处于一个待发放状态，等待管理员核对信息后，点击发放才行。我们当时的发放方式有两种一个是立刻发放，立刻发放就是优惠券立刻生效，会直接出现在用户端页面供用户领取。另有一个是考虑到会有过节发放优惠券的场景所以采用定时发放。定时发放则需要指定一个发放开始时间，时间到期后才会进入出现在用户端页面。

当时用MQ做了延时任务来定期完成发放功能。

而且无论是哪种发放方式，都需要指定一个过期时间，当优惠券过期后就会进入已结束状态，用户端页面无法领取。

当然，除了过期导致的结束发放以外，管理员也可以手动点击暂停发放：

另外，由于优惠券的领取方式不同，基于兑换码的优惠券还需要在发放时生成兑换码。

用户端优惠券的领取

优惠券的领取，我们是在我们的网站页面设置了一个领券中心，用户点击后，会显示当前可以领取的优惠券，以及应用的范围以及当前的优惠条件等。用户领取了优惠券，我们就会记录当前领取了哪一张优惠券，并且扣除这个优惠券的库存。这样很容易产生高并发问题，例如多个用户去挣抢同一张券，导致优惠券超卖，或者是同一个用户多次抢券，超过了持有券的上限等等。

我们采用了乐观锁的思想实现了多个用户去抢券可能会导致的超卖问题，在用户去更新数据库的扣减库存的时候，判断数据库中的库存数是大于被领取的数量，

一个用户多次抢券导致超过领取上限的问题，我们采用的是加锁，基于 redisson 的分布式锁来完成的。

保证用户的请求是串行化执行的。

由于业务逻辑较长，前置的判断过多，我们改为校验和数据库操作分离，校验成功后发送 mq 消息，再执行生成用户的优惠券和扣除优惠券库存。

兑换码的方式领取的时候与手动领取基本相同，多了校验兑换码是否正确，这里就不过多描述。

优惠券的使用

所以，用户券可以看做是用户和券的关系，即：谁领了哪张券。当然不仅仅是关系，因为它还要记录用户领完券后的使用情况。

因此，我们需要设计一个用户券的表，用来保存用户和券的关系、使用状态等信息。当用户领取优惠券时，我们需要保存一条数据到用户券表中。这就是领取优惠券功能。

当用户将商品加入购物车之后，点击去结算，然后进入一个预下单流程：为了避免重复下单生成订单id，查询可用的优惠策略，在这里我们考虑到优惠券有很多种类型以及他们组合在一起会有不同的优惠方案，就需要查询出所有的优惠券，先判断他们是否可用，然后将他们组合排列出所有的优惠方案，然后按照顺序计算每种方案所能优惠的价格，并筛选出一个最优惠的价格返回，这样用户就能很清楚的看到优惠方案，然后用户就去根据金额，然后去下单：查询优惠明细，创建订单，核销优惠券，接下来就是用户支付或者取消订单，取消订单：更新优惠状态，返回优惠券，最后就需要查询已下订单：查询订单进度，查询订单明细，查询优惠券的规则最后结束，

而在退款的时候，如果用户选择只退部分商品，我们就可以根据每个商品的实付金额来退款，实现订单拆分退款。同时也满足退款不退券的原则。

当然，如果订单未支付，直接取消或者超时关闭，是可以退还优惠券的。