商品服务(SKU、下单流程、购物车、优惠券设计)

一、两个概念SKU、SPU

SKU：最小库存单位(裤子—蓝色—XS大小---->对应一个库存)
SPU：商品具有的属性,不涉及到库存

(一)SKU相关表的设计：

(1) pms_product_attribute_category 商品属性表

通过attribute_count字段记录当前商品有多少个SKU属性在前端显示

(2) pms_product_attribute 商品属性参数表

product_attribute_category_id字段对应了商品属性表的id

注：商品属性表和商品属性参数表是 1对N的关系。

(3) pms_product_attribute_value 存储产品参数具体信息的表

 该表是更细的划分，product_id说明当前是哪个商品，product_attribute_id对应的商品属性参数表的内容，value是当前商品的具体属性参数(哪一个属性的具体值)

二、商品下单的流程(未涉及支付部分)

Step1:添加购物车

分析购物车

(1)购物车购物车是访问非常高频的场景，读写次数可能是最多的

(2)有的电商网站设置的即使不登陆仍然可以加入购物车,不计成本的直接加

(3)就分为了在线购物车和离线购物车

(4)在线购物车实际是会写入DB中的做持久化，那么为什么能抗住那么大的压力是因为用了分库分表的中间件(Sharding),路由到不同的库上去。

(5)读的时候，会选择用redis来抗读的压力

离线购物车是怎么实现的？

(1)离线购物车,可以存在cookie里面,但是cookie不安全,且可能购物车东西多会把cookie衬得很大。

(2)经实验发现，京东的离线购物车通过F12查看其Cookie信息，发现其中有一个唯一标志，可通过Redis的hash结构结合该全局唯一标志当作购物车的数据结构。

(3)Hash结构中，cookie唯一标志加上购物车id为key value是(产品的skuid，购买数量),可以通过redis的设置超时时间来限制购物车存在时间。

(4)购物车是有上限的（可以通过hash数据结构的 hlen key 获取当前购物车中的商品种类数量）

(5)登录之后，离线购物车的信息就会同步到DB里面去

(6)如果cookie被禁用，可以将信息存储在http的header里面。(和jwt是一样的)

Step2:根据购物车信息生成订单信息
购物车生成订单具体逻辑
1、get到购物车的实体信息set到订单实体信息中。
2、判断是否有库存，没有则抛出异常
3、判断是否使用了优惠券,用了优惠券需要判断当前用户使用的优惠券是否符合该商品类别(优惠券下一模块讲怎么设计)
4、对每个下单商品进行优惠券金额分摊的计算
5、判断是否使用积分，不适用积分，则订单中积分这块直接set为0
6、使用积分，则先判断积分是否可用，可用情况下分摊到可用商品中(通过数学公式计算)
7、计算实际商品价格：原价-促销优惠-优惠券抵扣-积分抵扣
8、进行库存锁定 原锁定库存数+当前购物车中下单数

为啥这么做？
在库存表中，有真实库存字段和锁定库存字段，未支付之前，是需要锁定库存的，因为不锁定而是直接减库存的话，假设原来真实库存有100件，那么最多只允许100个人下单，这100个人当中可能80个人退单，那么这样80%的退单率，800个人来下单才会把100个真正卖掉。所以不能直接减库存，需要设置一个锁库存的字段。

由其引出超卖现象：
超卖现象：200人支付了，但是库存不够，可以补充库存。不希望超卖怎么办？只有拒绝掉请求，并把支付到支付宝里的钱退还，走支付宝的退款流程
当然以上是应该跟产品经理去对的

（三）优惠券的设计

优惠券业务：
1、全场、会员、购物、注册赠券
2、适用平台：移动还是PC
3、门槛：例如满2000 面额50 总发行量
4、有效期

表的介绍：
（1）SMS_coupon 优惠券信息表

添加一个优惠券都会在这个表添加记录,记录了过期时间、优惠券简介

（2）sms_coupon_history优惠券使用、领取历史表

使用过的或者领取的都会记录在该表,包含使用状态，使用/领取人等

（3）sms_coupon_product_category_relation 优惠券和产品分类关系表

 标识优惠券适于指定分类有关 ,也就是标明了该商品分类可以用哪些优惠券

（4）sms_coupon_product_relation 优惠券和产品的关系表

标识优惠券适于指定商品有关

(四) 其他

计算钱的时候不要用double类型，而是用BigDecimal计算