商城特殊活动(内含秒杀)系统

商城特殊活动(内含秒杀)系统_第1张图片
商城特殊活动架构.png

特殊活动构成模块

  • 验证码
    • 产生验证码
      • 初始化产生100个验证码,每次按照当前时间ms%100获取一个验证码,保存至tair,超时为x分钟
      • 这里的校验码类似于token,每次请求都随机分配一个用户唯一的token并且保存至tair,这个token还有图片显示给前端
      • 用户需要手动输入这个图片里的验证码
      • 这样秒杀拼的系统是(分流不至于单点压力,提高机器人刷单行为成本)
        1. 用户点击秒杀按钮的速度
        2. 快速识别验证码和输入验证码的速度
    • 校验验证码
      • 发奖时要拿这个token对tair内token进行校验(觉得这个流程体验很不好)
    • 应该是token的生成和校验都是 代码自动做的,不需要额外的用户交互
  • 活动模块信息(商品列表)
    • 一个活动下面包含多个模块
    • 秒杀品模块推荐品模块(商品)[为了导流],其他模块(主题商品馆)[不一定需要],秒杀场次模块时间表
    • 包含的spu类型有, 优惠券/实物
    • 秒杀品应该只是spu/sku的特殊类型,当秒杀时间过期后,商品应该自动变为普通的spu/sku(我们现在的系统并不是这样的,而是单独把秒杀品和非秒杀品的订单流程分开,造成秒杀品订单不可逆)
    • 秒杀品只能是 b2c产品
    • 秒杀品的库存应该是 spu下面的sku对应总和,而我们的系统是将spu中的第一个sku作为卖品,而没有将spu中不同规格商品进行细分
  • 秒商品列表模块SPU库存信息
    • 单独module 下 spu list 库存信息查询接口
    • 批量获取一个module 下所有spu 的库存,保存至tair
  • 获取秒杀品详情
    • 商品信息(但是不显示秒杀品剩余库存信息)
  • 准备参与秒杀(京东\阿里的秒杀是不需要输入验证码)
    • 获取校验码
    • 正确输入校验码
  • 参与秒杀
    • 现有实现秒杀品到点前不允许抢购
    • 点击抢购后需要校验 token,风控 -> 扣减库存 -> 记录用户令牌 -> 记录用户参与信息( 这里采用单向链表模型,向后自动调用)
    • toke 校验,防止刷单,降低并发请求(就是一个验证码)
    • 风控 判断用户userId/设备deviceId是否已经参与过,用tair保存
    • 扣取 库存计数器 同时会将 spu 状态也保存在tair中,如果库存被扣完,则更新spu缓存状态,减少计数器压力[这里由于采用@Cacheable的方法,无法立即更新,spu的状态可能会需要本地缓存自动更新]
    • 发放用户令牌 生成用户唯一令牌
    • 记录用户/设备记录 防止用户重复参与,15分钟内不允许再使用
  • 创建秒杀订单
    • 我们将秒杀品下单独立了一个判断
    • 秒杀品不允许使用 健康金/优惠券/购物卡(京东是允许使用)坑比[非秒杀品, 是可以调用促销中心计算促销后订单金额]
    • 正常下单后,对用户进行风控(同一个设备,同一个用户,同一个spu,同一天内,n分钟内,只允许购买n次)[比较合理的控制是,一个秒杀品,只允许用户购买n次]
    • 由于采用同步调用创建订单服务,失败有多种原因,如果由于库存/商品不可用的原因,则立即清空缓存内的库存计数器。(这种原因是使用分桶策略,有可能有些分桶还存在库存,但是总库存已经不足,这时候应该马上清空全部分桶库存,同时将整个spu/sku置为不可用)

第三方组件选型

  • 缓存 Spring-Cache管理
    • 本地缓存 EhCache
      • 场次产品信息缓存全量至本地 每隔 n分钟, 重新从 db/第三方缓存 更新一次[这里面有n分钟的管理信息同步问题]
        • 可以做一个全局监控,当管理端刷新后,监控触发自动更新本地缓存[我们还没做这一个]
        • 采用 spring 4.2.x,存在 expire 后穿透至第三方缓存问题
    • 第三方缓存 Tair[支持持久化和非持久化]
      • 持久化 重要数据, 秒杀商品,库存(保存总库存/按策略分桶保存库存)
      • 非持久化
  • MQ RocketMQ
    • HessianUtils 对数据进行压缩
    • 注意 consumer/producer 之间序列化Object的问题,package path不对无法匹配

特殊活动应用设计的内容

  • 场次+奖品(商品/现金)=活动
    • 奖品分为 商品现金优惠券
      • 奖品 绑定场次,奖品不能多个场次共用(个人觉得不合理),现有方案认为运营的工作量能忍受,我个人觉得模型上有问题
      • 奖品 有时效性
        • 我的理解,当前奖品的时效性和优惠券的时效性冲突(如何确定真实时效性),但是实物(现金)又没有时效性需要奖品时间来控制(没理解)
        • 业务的时效性 又被理解为活动后台允许获取奖品的时间段,细分了每个奖品适用的范围段
    • 商品(spu)
      • 实物
        • 以抵用券的形式发放
      • 虚拟物(具体的物品详细到 sku)
        • 主客优惠券(使用) - 卖家承担成本
        • 话费充值卡
        • 流量充值卡
        • 主客无门槛券 - 商城承担成本
        • 抵用券 协商商户
    • 现金
      • 需要独立现金红包系统
      • 需要实现 账本 等等实现
    • 优惠券
      • 优惠券系统
      • 一个场次只会有一类优惠券

你可能感兴趣的:(商城特殊活动(内含秒杀)系统)