如何防止超发
如何大批量给用户发券
如何限定券的利用条件
如何防止用户重复领券
模型的设计
优惠券系统 Coupon System 模型定义
优惠券系统的难点
3.1 表单设计券批次（券模板），coupon_batch指一批优惠券的抽象、模板，包含优惠券的大部分属性。
如商家创建了一批优惠券，共1000张，利用韶光为2022-11-11 00:00:00 ~ 2022-11-11 23:59:59，规定只有数码类目商品才能利用，满100减50。
券发放到用户的一个实体，已与用户绑定。
如将某批次的优惠券中的一张发送给某个用户，此时优惠券属于用户。
规则优惠券的利用有规则和条件限定，比如满100减50券，须要达到门槛金额100元才能利用。
券批次表 coupon_batch
规则表 rule：
规则内容：
{ threshold: 5.01 // 利用门槛 amount: 5 // 优惠金额 use_range: 3 // 利用范围，0—全场，1—商家，2—种别，3—商品 commodity_id: 10 // 商品 id receive_count: 1 // 每个用户可以领取的数量 is_mutex: true // 是否互斥，true 表示互斥，false 表示不互斥 receive_started_at: 2020-11-1 00:08:00 // 领取开始韶光 receive_ended_at: 2020-11-6 00:08:00 // 领取结束韶光 use_started_at: 2020-11-1 00:00:00 // 利用开始韶光 use_ended_at: 2020-11-11 11:59:59 // 利用结束韶光 }
优惠券表 coupon：
create table t_coupon ( coupon_id int null comment '券ID，主键', user_id int null comment '用户ID', batch_id int null comment '批次ID', status int null comment '0-未利用、1-已利用、2-已过期、3-冻结', order_id varchar(255) null comment '对应订单ID', received_time datetime null comment '领取韶光', validat_time datetime null comment '有效日期', used_time datetime null comment '利用韶光' );优惠券系统建券
1、新建规则
INSERT INTO rule (name, type, rule_content) VALUES(“满减规则”, 0, '{ threshold: 100 amount: 10 ...... }');
2、新建优惠券批次
INSERT INTO coupon_batch (coupon_name, rule_id, total_count ) VALUES(“劳斯莱斯5元代金券”, 1010, 10000);发券
如何给大量用户发券？
异步发送
触达系统短信、邮件可通过调用第三方接口的办法实现站内信通过数据库插入记录来实现信息表 message
create table t_message ( id int null comment '信息ID', send_id int null comment '发送者id', rec_id int null comment '接管者id', content vachar(255) comment '站内信内容', is_read int null comment '是否已读', send_time datetime comment '发送韶光' ) comment '信息表';
先考虑用户量很少的情形，商家要给所有人发站内信，则先遍历用户表，再按照用户表中的所有用户依次将站内信插入到 message 表中。这样，如果有100个用户，则群发一条站内信要实行100个插入操作。
系统用户数增加到万级发一条站内信，就得重复插入上万条数据。而且这上万条数据的 content 一样！
假设一条站内信占100K，发一次站内信就要花费十几M。对此，可将原来的表拆成两个表：
信息表 message
信息内容表 message_content
发一封站内信的步骤往 message_content 插入站内信的内容在 message 表中，给所有用户插入一条记录，标识有一封站内信千w级用户数
这就有【非生动用户】的问题，假设注册用户一千万，根据二八原则，个中生动用户占20%。若采取上面拆成两个表的情形，发一封“站内信”，得实行一千万个插入操作。可能剩下80%用户基本都不会再登录，实在只需对个中20%用户插入数据。
信息表 message：
create table t_message ( id int null comment '信息 ID', # send_id int null comment '发送者 id', 去除该字段 rec_id int null comment '接管者 id', message_id int null comment '外键，信息内容', is_read int null comment '是否已读' ) comment '信息表';
create table t_message_content ( id int null comment '信息内容id', send_id int null comment '发送者id', content varchar(255) null comment '内容', send_time datetime null comment '发送韶光' );用户侧操作
登录后，首先查询 message_content 中的那些没有在 message 中有记录的数据，表示是未读的站内信。在查阅站内信的内容时，再将干系的记录插入 message。
系统侧操作发站内信时：
只在 message_content 插入站内信的主体内容message 不插入记录假设商家要给 10W 用户发券有什么问题？重复消费，导致超发！
# 记住利用事务哦！领券步骤校验优惠券余量
INSERT INTO coupon (user_id, coupon_id，batch_id) VALUES(1001, 66889, 1111); UPDATE coupon_batch SET total_count = total_count - 1, assign_count = assign_count + 1 WHERE batch_id = 1111 AND total_count > 0;
SELECT total_count FROM coupon_batch WHERE batch_id = 1111; 新增优惠券用户表，扣减余量
# 把稳事务！
INSERT INTO coupon (user_id, coupon_id，batch_id) VALUES(1001, 66889, 1111); UPDATE coupon_batch SET total_count = total_count - 1, assign_count = assign_count + 1 WHERE batch_id = 1111 AND total_count > 0;
用户领券过程中，实在也会涌现类似秒杀场景。秒杀场景下会有哪些问题，如何办理？
办理用户重复领取或多领
Redis 数据校验！
# 判断成员元素是否是凑集的成员 SISMEMBER KEY VALUE SISMEMBER batch_id:1111:user_id 1001领券领券后，更新缓存
# 将一或多个成员元素加入到凑集中，已经存在于凑集的成员元素将被忽略 SADD KEY VALUE1......VALUEN SADD batch_id:1111:user_id 1001用券
何时校验优惠券利用规则？
确认订单（√）提交订单立即付款确认订单页，对优惠券进行校验：
判断是否过期判断适用范围判断是否达到门槛判断是否互斥返回可用券 SELECT batch_id FROM coupon WHERE user_id = 1001 AND status = 0; SELECT rule_id FROM coupon_batch WHERE batch_id = 1111; SELECT name, type, rule_content FROM rule WHERE rule_id = 1010;选择可用券，并返回结果
优惠券操作记录表 Coupon_opt_record
create table t_coupon_opt_record ( user_id int null comment '用户id', coupon_id int null comment '优惠券id', operating int null comment '操作，0-锁定、1-核销、2-解锁', operated_at datetime null comment '操作韶光' );
TCC，Try-Confirm-Cancel，目前分布式事务主流办理方案。
阶段一：Try对资源进行冻结，预留业务资源
创建订单时，将优惠券状态改为 “冻结”
阶段二：Confirm确认实行业务操作，做真正提交，将第一步Try中冻结的资源，真正扣减
订单支付成功，将优惠券状态改为 “已利用”
阶段三：Cancel取消实行业务操作，取消Try阶段预留的业务资源
支付失落败/超时或订单关闭情形，将优惠券状态改为 “未利用”
Scale扩展快过期券提醒定时扫券表
缺陷：扫描数据量太大，随着历史数据越来越多，会影响线上主业务，终极导致慢SQL。
延时缺陷：有些券的有效韶光太长了(30天)以上，有可能造成大量 MQ 积压
新增关照表优点：扫描的数据量小，效率高。删除无用的已关照的数据记录
关照信息表（notify_msg）设计 create table t_notify_msg ( id bigint auto_increment comment '自增主键', coupon_id bigint null comment '券id', user_id bigint null comment '用户id', notify_day varchar(255) null comment '须要实行关照的日期', notify_type int null comment '关照类型，1-过期提醒', notif_time timestamp null comment '关照的韶光，在该韶光戳所在天内关照', status int null comment '关照状态，0-初始状态、1-成功、2-失落败', constraint t_notify_msg_id_uindex unique (id) ); alter table t_notify_msg add primary key (id);
过期券提醒：
在创建优惠券的时候就将须要提醒的记录插入提醒表中notify_msg把用户ID+批次ID+关照日期作为唯一索引，防止同一个批次有重复的记录关照，担保每天只会被关照一次建立notify_time，关照韶光索引，逐日的关照扫描通过该索引列查询，通过索引列来提高查询效率关照完成后该表中的数据变失落去了意义，通过定时任务将该数据删除数据库层面优化 - 索引发券接口，限流保护前端限流
点击一次后，按钮短韶光内置灰
后端限流
部分要求直接跳转到【繁忙页】