如何设计一个优惠卷系统

Posted 热爱编程的大忽悠

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何设计一个优惠卷系统相关的知识,希望对你有一定的参考价值。

如何设计一个优惠卷系统


场景

电商大厂常见促销手段:

  • 优惠券
  • 拼团
  • 砍价
  • 老带新

优惠券的种类

  • 满减券
  • 直减券
  • 折扣券

优惠券系统的核心流程

发券

发券的方式:同步发送 or 异步发送

领券

  • 谁能领?

    所有用户 or 指定的用户

  • 领取上限

    一个优惠券最多能领取多少张?

  • 领取方式

    用户主动领取 or 自动发放被动领取

用券

  • 作用范围

    商品、商户、类目

  • 计算方式

    是否互斥、是否达到门槛等


需求拆解

商家侧

  • 创建优惠券
  • 发送优惠券

用户侧

  • 领取优惠券
  • 下单
  • 使用优惠券
  • 支付

编码

Service 服务

服务结构设计


优惠券系统设计技术难点

  • 券的分布式事务,使用券的过程会出现的分布式问题分析?
  • 如何防止超发?
  • 如何大批量给用户发券?
  • 如何限制券的使用条件?
  • 如何防止用户重复领券?

Storage存储

表单设计

券批次(券模板),coupon_batch

指一批优惠券的抽象、模板,包含优惠券的大部分属性。

如商家创建了一批优惠券,共1000张,使用时间为2022-11-11 00:00:00 ~ 2022-11-11 23:59:59,规定只有数码类目商品才能使用,满100减50。

  • 券批次表 coupon_batch:
DROP TABLE IF EXISTS coupon_batch;
CREATE TABLE coupon_batch
(
    id           INT          NOT NULL AUTO_INCREMENT COMMENT '主键',
    batch_id     INT          NOT NULL COMMENT '批次ID',
    batch_name   VARCHAR(50)  NOT NULL COMMENT '批次名称',
    coupon_name  VARCHAR(50)  NOT NULL COMMENT '劵名称',
    rule_id      INT          NOT NULL COMMENT '规则,外键',
    total_count  INT          NOT NULL COMMENT '总数量',
    assign_count INT          NOT NULL COMMENT '已发放劵数量',
    used_count   INT          NOT NULL COMMENT '已使用劵数量',
    create_Time  timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_Time  timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP (0),
    PRIMARY KEY (`id`) USING BTREE,
    KEY          batch_id_index(batch_id)
)ENGINE = InnoDB AUTO_INCREMENT = 0 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

批次ID不重复,并且按照批次ID查询需求频繁,因此适合建立一个单值索引,不选择唯一索引是因为,对于劵批次表来说,修改也同样频繁,唯一索引无法利用change buffer进行懒修改操作,而普通索引可以,并且普通索引在查询性能上与唯一索引相差也不是很多。


发放到用户的一个实体,已与用户绑定。

如将某批次的优惠券中的一张发送给某个用户,此时优惠券属于用户。

  • 优惠券表 coupon:
DROP TABLE IF EXISTS coupon;
CREATE TABLE coupon
(
    id            INT          NOT NULL AUTO_INCREMENT COMMENT '主键',
    user_id       INT          NOT NULL COMMENT '用户ID',
    batch_id      INT          NOT NULL COMMENT '批次ID',
    status        INT          NOT NULL COMMENT '0-未使用,1-已使用,2-已过期,3-冻结',
    order_id      varchar(255) NULL COMMENT '对应订单ID,优惠卷未使用之前,对应订单ID为NULL',
    received_time datetime     not null comment '领取时间',
    validate_time datetime     not null comment '有效日期',
    used_time     datetime     not null comment '使用时间',
    create_Time   timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_Time   timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP (0),
    PRIMARY KEY (`id`) USING BTREE,
    KEY           coupon_userId_index(user_id),
    KEY           coupon_batchId_index(batch_id)
)ENGINE = InnoDB AUTO_INCREMENT = 0 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

规则

优惠券的使用有规则和条件限制,比如满100减50券,需要达到门槛金额100元才能使用。

  • 规则表 rule:
DROP TABLE IF EXISTS rule;
CREATE TABLE rule
(
    id           INT          NOT NULL AUTO_INCREMENT COMMENT '主键',
    name         VARCHAR(50)  NOT NULL COMMENT '规则名称',
    type         INT          NOT NULL COMMENT '优惠卷类型, 0-满减, 1-折扣',
    rule_content BLOB         NOT NULL COMMENT '规则内容',
    create_Time  timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_Time  timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP (0),
    PRIMARY KEY (`id`) USING BTREE,
)ENGINE = InnoDB AUTO_INCREMENT = 0 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
  • 规则内容:
 
  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 // 使用结束时间 

规则内容实际是一串由key:value组成的JSON字符串,每一对key和value对应一组规则,我们可以通过增加key:value来完成规则内容的动态修改。

每一组规则后端对应提供一个过滤器进行解析,具体实现细节后面会展开论述。


完整sql文件如下:

USE
coupon;
DROP TABLE IF EXISTS coupon_batch;
CREATE TABLE coupon_batch
(
    id           INT          NOT NULL AUTO_INCREMENT COMMENT '主键',
    batch_id     INT          NOT NULL COMMENT '批次ID',
    batch_name   VARCHAR(50)  NOT NULL COMMENT '批次名称',
    coupon_name  VARCHAR(50)  NOT NULL COMMENT '劵名称',
    rule_id      INT          NOT NULL COMMENT '规则,外键',
    total_count  INT          NOT NULL COMMENT '总数量',
    assign_count INT          NOT NULL COMMENT '已发放劵数量',
    used_count   INT          NOT NULL COMMENT '已使用劵数量',
    create_Time  timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_Time  timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP (0),
    PRIMARY KEY (`id`) USING BTREE,
    KEY          batch_id_index(batch_id)
)ENGINE = InnoDB AUTO_INCREMENT = 0 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

DROP TABLE IF EXISTS rule;
CREATE TABLE rule
(
    id           INT          NOT NULL AUTO_INCREMENT COMMENT '主键',
    `name`       VARCHAR(50)  NOT NULL COMMENT '规则名称',
    type         INT          NOT NULL COMMENT '优惠卷类型, 0-满减, 1-折扣',
    rule_content BLOB         NOT NULL COMMENT '规则内容',
    create_Time  timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_Time  timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP (0),
    PRIMARY KEY (`id`) USING BTREE
)ENGINE = InnoDB AUTO_INCREMENT = 0 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;


DROP TABLE IF EXISTS coupon;
CREATE TABLE coupon
(
    id            INT          NOT NULL AUTO_INCREMENT COMMENT '主键',
    user_id       INT          NOT NULL COMMENT '用户ID',
    batch_id      INT          NOT NULL COMMENT '批次ID',
    status        INT          NOT NULL COMMENT '0-未使用,1-已使用,2-已过期,3-冻结',
    order_id      varchar(255) NULL COMMENT '对应订单ID,优惠卷未使用之前,对应订单ID为NULL',
    received_time datetime     not null comment '领取时间',
    validate_time datetime     not null comment '有效日期',
    used_time     datetime     not null comment '使用时间',
    create_Time   timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_Time   timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP (0),
    PRIMARY KEY (`id`) USING BTREE,
    KEY           coupon_userId_index(user_id),
    KEY           coupon_batchId_index(batch_id)
)ENGINE = InnoDB AUTO_INCREMENT = 0 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

创建优惠卷

我们需要先理清楚创建一个优惠卷的业务流程是什么,这里以sql语句的形式先展示出来:

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个插入操作。

这其实是推消息的操作,当消息发送者发出一条消息后,会往所有消费者邮箱中塞入一条消息记录。


系统用户数增加到w级:

发一条站内信,就得重复插入上万条数据。而且这上万条数据的 content 一样!假设一条站内信占100K,发一次站内信就要消耗十几M。对此,可将原来的表拆成两个表:

  • 信息表 message

  • 信息内容表 message_content

发一封站内信的步骤

  1. 往 message_content 插入站内信的内容
  2. 在 message 表中,给所有用户插入一条记录,标识有一封站内信

这样就避免通过推操作往多个用户邮箱塞入消息时,都需要携带重复的消息体数据了


千w级用户数

这就有【非活跃用户】的问题,假设注册用户一千万,根据二八原则,其中活跃用户占20%。若采用上面拆成两个表的情况,发一封“站内信”,得执行一千万个插入操作。可能剩下80%用户基本都不会再登录,其实只需对其中20%用户插入数据。

需要将用户进行冷热分离,冷用户指的是近期非活跃用户,热用户指的是近期活跃用户,然后采用推拉的模式进行消息推送。

消息只会主动推送给活跃用户,而非活跃用户需要在下次登录时,再主动进行消息拉取。

信息表 message:

create table 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 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 中有记录的数据,表示是未读的站内信。在查阅站内信的内容时,再将相关的记录插入 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;

领券

步骤

  1. 校验优惠券余量
SELECT total_count FROM coupon_batch WHERE batch_id = 1111;
  1. 新增优惠券用户表,扣减余量
# 注意事务!
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
  1. 领券
  2. 领券后,更新缓存
# 将一或多个成员元素加入到集合中,已经存在于集合的成员元素将被忽略
SADD KEY VALUE1......VALUEN
SADD batch_id:1111:user_id 1001

用券

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

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

  • 阶段一:Try

对资源进行冻结,预留业务资源

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

  • 阶段二:Confirm

确认执行业务操作,做真正提交,将第一步Try中冻结的资源,真正扣减

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

  • 阶段三:Cancel

取消执行业务操作,取消Try阶段预留的业务资源

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


扩展

快过期券提醒

  • 定时扫券表

缺点:扫描数据量太大,随着历史数据越来越多,会影响线上主业务,最终导致慢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. 通知完成后该表中的数据变失去了意义,通过定时任务将该数据删除

数据库层面优化 - 索引



发券接口,限流保护

前端限流

点击一次后,按钮短时间内置灰

后端限流

部分请求直接跳转到【繁忙页】

以上是关于如何设计一个优惠卷系统的主要内容,如果未能解决你的问题,请参考以下文章

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

优惠卷秒杀系统设计秒杀优化 —— 基于阻塞队实现异步秒杀优化 及 基于Lua脚本判断秒杀库存一人一单

优惠卷秒杀系统设计全局唯一ID生成,秒杀下单,分析解决库存超卖(乐观锁)实现一人一单秒杀业务(对用户id加锁)集群模式下并发问题

如何在百度地图中查看周边商家优惠信息呀

互联网大厂的支付系统的安全性应该是如何设计的?

联盟商家系统开发像美团一样的