大厂的优惠券系统是如何设计的?(二)

mb628db8cb0e5b3
发布于 2022-6-2 16:33
浏览
0收藏

 

千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 用户发券
     大厂的优惠券系统是如何设计的?(二)-鸿蒙开发者社区

有什么问题?重复消费,导致超发!

  1. 运营提供满足条件的用户文件,上传到发券管理后台并选择要发送的优惠券
  2. 管理服务器根据【用户ID】、【券批次ID】生成消息,发送到MQ
  3. 优惠券服务器消费消息
    # 记住使用事务哦!
    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;​

     

 

 

3.4 领券
步骤
1.校验优惠券余量

SELECT total_count FROM coupon_batch 
  WHERE batch_id = 1111;

 

2.新增优惠券用户表,扣减余量

# 注意事务!
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 数据校验!

1.领券前,先查缓存

# 判断成员元素是否是集合的成员
SISMEMBER KEY VALUE
SISMEMBER batch_id:1111:user_id 1001


2.领券
3.领券后,更新缓存

# 将一或多个成员元素加入到集合中,已经存在于集合的成员元素将被忽略 
SADD KEY VALUE1......VALUEN
SADD batch_id:1111:user_id 1001


3.5 用券

何时校验优惠券使用规则?

  1. 确认订单(√)
  2. 提交订单
  3. 立即付款
    确认订单页,对优惠券进行校验:
  • 判断是否过期
  • 判断适用范围
  • 判断是否达到门槛
  • 判断是否互斥
     
    返回可用券

大厂的优惠券系统是如何设计的?(二)-鸿蒙开发者社区

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,目前分布式事务主流解决方案。


1.阶段一:Try
对资源进行冻结,预留业务资源

创建订单时,将优惠券状态改为 “冻结”

2.阶段二:Confirm
确认执行业务操作,做真正提交,将第一步Try中冻结的资源,真正扣减

订单支付成功,将优惠券状态改为 “已使用”

3.阶段三:Cancel
取消执行业务操作,取消Try阶段预留的业务资源

支付失败/超时或订单关闭情况,将优惠券状态改为 “未使用”

大厂的优惠券系统是如何设计的?(二)-鸿蒙开发者社区

4 Scale 扩展

4.1 快过期券提醒
定时扫券表
缺点:扫描数据量太大,随着历史数据越来越多,会影响线上主业务,最终导致慢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);


过期券提

  1. 在创建优惠券的时候就将需要提醒的记录插入提醒表中notify_msg
  2. 把用户ID+批次ID+通知日期作为唯一索引,防止同一个批次有重复的记录通知,保证每天只会被通知一次
  3. 建立notify_time,通知时间索引,每日的通知扫描通过该索引列查询,通过索引列来提高查询效率
  4. 通知完成后该表中的数据变失去了意义,通过定时任务将该数据删除
    4.2 数据库层面优化 - 索引
     大厂的优惠券系统是如何设计的?(二)-鸿蒙开发者社区

大厂的优惠券系统是如何设计的?(二)-鸿蒙开发者社区

4.3 发券接口,限流保护
前端限流
点击一次后,按钮短时间内置灰

大厂的优惠券系统是如何设计的?(二)-鸿蒙开发者社区

后端限流
部分请求直接跳转到【繁忙页】

 

文章转自公众号: JavaEdge

分类
标签
已于2022-6-2 16:33:29修改
收藏
回复
举报
1条回复
按时间正序
/
按时间倒序
wx6416cb1660352
wx6416cb1660352

感谢大神指点,给跪了

言简意赅,该说的都说了,相当受益


回复
2023-3-19 16:43:48
回复
    相关推荐