如何设计一个优惠卷系统

  • 场景
    • 优惠券的种类
    • 优惠券系统的核心流程
      • 发券
      • 领券
      • 用券
    • 需求拆解
      • 商家侧
      • 用户侧
  • 编码
    • Service 服务
      • 服务结构设计
      • 优惠券系统设计技术难点
    • Storage存储
      • 表单设计
        • 券批次（券模板），coupon_batch
        • 券
        • 规则
      • 创建优惠卷
      • 发劵
      • 领券
      • 用券
  • 扩展
    • 快过期券提醒
    • 数据库层面优化 - 索引
    • 发券接口，限流保护
      • 前端限流
      • 后端限流

场景

电商大厂常见促销手段：

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

优惠券的种类

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

优惠券系统的核心流程

发券

发券的方式：同步发送 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 + 1WHERE 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 + 1WHERE 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_uindexunique (id)
);alter table t_notify_msgadd primary key (id);

过期券提醒:

  1. 在创建优惠券的时候就将需要提醒的记录插入提醒表中notify_msg
  2. 把用户ID+批次ID+通知日期作为唯一索引，防止同一个批次有重复的记录通知，保证每天只会被通知一次
  3. 建立notify_time，通知时间索引，每日的通知扫描通过该索引列查询，通过索引列来提高查询效率
  4. 通知完成后该表中的数据变失去了意义，通过定时任务将该数据删除

数据库层面优化 - 索引


发券接口，限流保护

前端限流

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

后端限流

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

如何设计一个优惠卷系统相关推荐

  1. 面试总结day7:工厂模式以及如何设计一个优惠卷兑换码

    1.设计一个优惠卷兑换码怎么弄 我们自己设计了一个表(uid,goodsid,shopid-)兑换码.商品id.商家id 然后每次支付完成后,生产一条记录,每次扫码后的二维码就可以这找到对应的信息. ...

  2. mysql每秒支持多少并发_如何设计一个高并发系统？

    面试题 如何设计一个高并发系统? 面试官心理分析 说实话,如果面试官问你这个题目,那么你必须要使出全身吃奶劲了.为啥?因为你没看到现在很多公司招聘的 JD 里都是说啥,有高并发就经验者优先. 如果你确 ...

  3. oom 如何避免 高并发_【面试题】如何设计一个高并发系统？

    面试题 如何设计一个高并发系统? 原文链接:https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/high- ...

  4. 面试题：如何设计一个高并发系统？

    面试官心理分析 说实话,如果面试官问你这个题目,那么你必须要使出全身吃奶劲了.为啥?因为你没看到现在很多公司招聘的 JD 里都是说啥,有高并发就经验者优先. 如果你确实有真才实学,在互联网公司里干过高 ...

  5. fifo页面置换算法设计思路_千万级并发！如何设计一个多级缓存系统？

    什么是一个多级缓存系统?它有什么用?我们又如何设计一个多级缓存系统? 图片来自 Pexels 所谓多级缓存系统,就是指在一个系统的不同的架构层级进行数据缓存,以提升访问效率. 我们都知道,一个缓存系统 ...

  6. 高并发面试 - 如何设计一个高并发系统？

    高并发面试 - 如何设计一个高并发系统? 面试题 如何设计一个高并发系统? 面试官心理分析 说实话,如果面试官问你这个题目,那么你必须要使出全身吃奶劲了.为啥?因为你没看到现在很多公司招聘的 JD 里 ...

  7. 【面试】如何设计一个高并发系统

    一.为什么需要秒杀系统? 电商平台本质是在线上撮合买卖双方的购销需求,达成交易.虽然是线上交易,但也遵守朴素的经济学原理,供求关系决定了商品的经济活动.当供求平衡时,买方和卖方处于对等关系,双方相对稳 ...

  8. 主题 04：如何设计一个复杂的系统（下）

    1. 引言 设计复杂系统的能力是高阶工程师的必备能力,设计出完备.健壮.优雅.前瞻的系统是工程师的不懈追求.在上一篇文章中,笔者介绍了设计一个复杂系统的第一步:深入理解业务.本文作为<如何设计一 ...

  9. 如何设计一个单点登录系统

    本文来说下如何设计一个单点登录系统 文章目录 概述 JWT的组成 头部(Header) 载荷(Payload) 签名(签名) 签名的目的 信息会暴露 JWT的适用场景 用户认证八步走 和Session ...

最新文章

  1. Java基础：面向对象
  2. WGAN的提出背景以及解决方案
  3. mysql数据库操作语句大全
  4. 130506datafile和tablespace offline区别
  5. 前端学习（2530）：使用computed获取数据
  6. 2019年Java开发者进阶手册.pdf
  7. ibatis 如何直接执行sql语句
  8. 被Redis击穿的一次面试经历
  9. python运行系统_python执行系统命令的方法
  10. 兼容IE和FF的js脚本做法
  11. BP(BackPropagation)神经网络算法详解
  12. 基于mysql的电商用户分析
  13. 错误 请再次按下快门释放按钮
  14. 2022年成考（专升本）考试政治练习题及答案
  15. iphone safaric中将mp4保存到本地相册
  16. 算法总结——大整数加法
  17. Python 解决execjs._exceptions.ProgramError: ReferenceError: document is not defined报错问题
  18. 图神经网络通用框架信息传递网络（MPNNs）
  19. ArcGIS如何将Excel表格转换为SHP格式
  20. The 19th Zhejiang Provincial Collegiate Programming Contest

热门文章

  1. 找了一下午的错误 ~
  2. 《青木瓜之味》观后感——爱情是什么
  3. [M贪心] lc1846. 减小和重新排列数组后的最大元素(贪心+双周赛51_3)
  4. 【工具使用系列】Windows 10 平台下的TTS工具 Balabolka
  5. 微机原理和计算机硬件基础知识,微机原理与接口技术
  6. 编写radware的负载配置
  7. Oracle Edition-Based Redefinition（EBR）理论与实践
  8. fabric systemd journalctl
  9. 设计 VS 架构 VS 框架
  10. Zend\Mail进阶：在ZF2的邮件中使用模板、多个附件以及用DI整合