大厂的优惠券系统是如何设计的？（二）

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 用户发券

有什么问题？重复消费，导致超发！

运营提供满足条件的用户文件，上传到发券管理后台并选择要发送的优惠券
管理服务器根据【用户ID】、【券批次ID】生成消息，发送到MQ

优惠券服务器消费消息

# 记住使用事务哦！
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 用券

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

确认订单（√）
提交订单
立即付款
确认订单页，对优惠券进行校验：

判断是否过期
判断适用范围
判断是否达到门槛
判断是否互斥

返回可用券

大厂的优惠券系统是如何设计的？（二）-鸿蒙开发者社区

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);

过期券提