商城特殊活动架构.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)
      • 主客优惠券(使用) - 卖家承担成本
      • 话费充值卡
      • 流量充值卡
      • 主客无门槛券 - 商城承担成本
      • 抵用券 协商商户
  • 现金
    • 需要独立现金红包系统
    • 需要实现 账本 等等实现
  • 优惠券
    • 优惠券系统
    • 一个场次只会有一类优惠券