vivo 全球商城：优惠券系统架构设计与实践( 三 ) _系统架构

1）如何保证性能
领取多张券，如果每张券分别进行校验、库存扣减、入库，那么接口性能的瓶颈卡在券的数量上，数量越多，性能直线下降。那么在券数量多的情况下，怎么保证高性能呢？主要采取两个措施：

a. 批量操作。
从发券流程来看，瓶颈在于券的入库。领券是实时的（异步的话，不能实时将券发到用户账户下，影响到用户的体验还有券的转化率），券越多，入库时与数据库的IO次数越多，性能越差。批量入库可以保证与数据库的IO的次数只有一次，不受券的数量影响。如上所述，用户优惠券数据做了分库分表，同一用户的优惠券资产保存在同一库表中，因此同一用户可实现批量入库。

b. 限制单次领券数量。
设置阀值，超出数量后，直接返回，保证系统在安全范围内。

2）保证高并发情况下，用户不会超领
假如用户在商城发起请求，一键领取A/B/C/D四张券，同时活动系统给用户发放券A ，这两个领券请求是同时的。其中，券A限制了每个用户只能领取一张。按照前述采用分布式锁保证校验的准确性，两次请求的分布式锁的key分别为：

用户id+A_id+B_id+C_id+D_id
用户id+A_id

这种情况下，两次请求的分布式锁并没有发挥作用，因为锁key是不同，数量校验依旧存在错误的可能性。为避免批量领券过程中用户超领现象的发生，在批量领券过程中，对分布锁的获取进行了改造。上例一键领取A/B/C/D四张券，需要批量获取4个分布式锁，锁key为：

用户id+A_id
用户id+B_id
用户id+C_id
用户id+D_id

获取其中任何一个锁失败，即表明此时该用户正在领取其中某一张券，需要自旋等待（在超时时间内）。获取所有的分布式锁成功，才可以进行下一步。
接口幂等性
统一领券接口需保证幂等性（幂等性：用户对于同一操作发起的一次请求或者多次请求的结果是一致的）。在网络超时、异常情况下，领券结果没有及时返回，业务方会进行领券重试。如果接口不保证幂等性，会造成超发。幂等性的实现有多种方案，优惠券系统利用数据库的唯一索引来保证幂等。
领券最早是不支持幂等性的，表设计没有考虑幂等性。
那么第一个需要考虑的问题：在哪个表来添加唯一索引呢？
无非两种方案：现有的表或者新建表。

采用现有的表，不需要增加表的关联。但如上所述，因为做了分库分表，大量的表需要添加唯一字段，并且需要兼容历史数据，需要保证历史数据新增字段的唯一性。
采用新建表这种方式，不需要兼容历史数据，但缺陷也很明显，增加了一层表的关联，对性能和现有逻辑都有很大影响。综合考虑，我们选取了在现有表添加唯一字段这种方式，这样更利于保证性能和后续的维护性。

第二个考虑的问题：怎么兼容历史数据和业务方？历史数据增加了唯一字段，需要填入唯一值，不然无法添加唯一索引。我们采用脚本刷数据的方式，构造唯一值并刷新到每一行历史数据中。优惠券已对接的业务方没有传入唯一编码，针对这种情况，优惠券则生成唯一编码作为替代，保证兼容性。
3.2.2 定向发券
定向发券用于运营在后台针对特定人群进行发券。定向发券可以弥补用户主动领券，人群覆盖不精准、覆盖面不广的问题。通过定向发券，可以精准覆盖特定人群，提高下单转化率。在大促期间，大范围人群的定向发券还可以承载活动push和降价促销双重任务。
定向发券主要在于人群的圈选和发券流程的设计，整体流程如下：