Java生鲜电商平台-生鲜电商限时抢购功能设计与代码实战(小程序/APP)

Java生鲜电商平台-生鲜电商限时抢购功能设计与代码实战(小程序/APP) 

说明：很多生鲜电商都有限时抢购功能，我们都知道限时抢购为促销的一种，限时抢购的营销目的：单品营销，主要通过营销手段打造低价心智。

           参与限时抢购的商品一般多为品牌溢价较低的商品，商家选择滞销品、流量品、换季品打造低价，通过低价销售的渠道销售出去。

            对于进入这个渠道的用户来说，他们的最终诉求是有足够便宜的商品，对于品质、品牌要求并不高

目录

1.项目背景与案例分析

2.数据库设计与代码实践

1.项目背景与案例分析

   我们先分析拼多多.这个是以价格低廉为基础的电商系统.(特别的老人很喜欢，因为便宜，他们不讲品牌，只讲价格)

拼多多

选品：基本选品为生活必须品，非品牌的商品较多，品牌商品以尾货特价的方式来做，这样的选品策略能打造出足够低的商品价格，符合限时秒杀想要打造的效果

最低价凸显:每一个页面入口都标记商品最低价格，吸引用户点击进去

从众心理：一部分页面会限时正有XX人在浏览、已有xx人拼团成功，利用人们的从众心理，缩短用户的决策链路

时间紧迫：限时抢购凸显限时特点，在活动页限时倒计时，让用户有一种紧迫感，加快用户下单的决策

便宜心理：以“万人团价”、“补贴价”、“清仓价”、“断码价”让用户觉得是有真实便宜的

总结：根据拼多多的业务场景分析：

限时抢购其实大致可以分为两类：平台与自营。自营一般利用滞销、尾货、换季来换取低价，转化价格敏感的用户；平台一般以销量和流量来和商家换取低价商品，对于用户来说是一个低价选货的入口，一般平台的商品较多，大致会分为品牌闪购和限时抢购两大块，根据不同维度（即将告罄、爆款榜单、量贩购）等营销形式帮助用户选择最便宜的商品，是价格敏感流量的转化地。

2.数据库设计与代码实践

  今天这篇文章以抛砖引玉的作用，可能大家都认为是需要用redis以及其他的缓存来做，原因就是数据量很大，并发量很高，要求及时性很强等等

那么不使用缓存（redis、memcache），如何设计高效抢购业务呢？
常见的抢购业务主要有：
商品抢购
券抢购
红包抢购
今天咱们就谈谈如何对这些抢购业务做统一设计，只使用Mysql做高并发活动。
我们先看下面一张表，分别标出了这三类业务涉及到的核心数据量：

核心数据量

数据量	商品库存	券库存	红包库存	数据金额
1.总量	totalNum	totalNum	totalMoney	总金额
2.销售量	sellNum	sellNum	sellMoney	领取金额
3.锁定量	lockNum	lockNum	0	锁定金额
4.库存量	stockNum	stockNum	stockMoney	库存金额
5.退货量	refundNum	refundNum	0	0
6,库存池	inventory	inventory	-	-

我们再看下这些业务涉及到的核心节点的数据量变化

核心数据量变化(变化量为n)

节点名称	总量	销售量	锁定量	库存量	退货量
下单	totalNum不变	sellNum不变	lockNum+n	stockNum不变	refundNum不变
取消订单	totalNum不变	sellNum不变	lockNum-n	stockNum不变	refundNum不变
支付	totalNum不变	sellNum+n	lockNum-n	stockNum-n	refundNum不变
核销	totalNum不变	sellNum不变	lockNum不变	stockNum不变	refundNum不变
退款	totalNum不变	sellNum-n(或不变)	lockNum不变	stockNum+n(或不变)	refundNum+n

节点设计

我们知道，每个操作节点最少可对应一个操作。而我们为了保证接口效率最高，我们需要尽量少的使用sql操作，如果每个接口只有一次数据操作那是最好的。
但是，每个接口的逻辑可能都会涉及到若干数据业务操作，而我们为了能让这些抢购业务性能尽量好，那我们就要尽量把接口原子化设计。而在这些接口中，下单操作时重中之重，只要把这个下单接口设计好了，后续流程基本都没啥大问题。

下单接口设计

那我们来分析一下下单接口的设计业务：
检查库存是否够用
防止并发超卖
锁库存
等等...
那这些要求改如何同时满足呢？那就要我们尽量合理使用核心数据量了！

那我们在设计库存表的时候，尽量把总量、销售量、锁定量、库存量放到一起，可以如下设计：

CREATE TABLE `goods_stock` (
  `ID` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `SPU_ID` bigint(20) NOT NULL DEFAULT '0' COMMENT '商品SPU_ID',
  `SKU_ID` bigint(20) NOT NULL DEFAULT '0' COMMENT '商品SKU ID',
  `STOCK_LEFT_NUM` int(11) NOT NULL DEFAULT '0' COMMENT '剩余库存数量',
  `STOCK_SALE_NUM` int(11) NOT NULL DEFAULT '0' COMMENT '售卖库存数量',
  `STOCK_LOCK_NUM` int(11) NOT NULL DEFAULT '0' COMMENT '被锁定的库存数量',
  `STOCK_TOTAL_NUM` int(11) NOT NULL DEFAULT '0' COMMENT 'SKU总库存量,0表示不限制库存',
  `STATUS` tinyint(4) NOT NULL DEFAULT '0' COMMENT '本条记录状态，0-有效，1-无效',
  `CREATE_TIME` datetime NOT NULL COMMENT '创建时间',
  `UPDATE_TIME` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `VERSION` int(11) NOT NULL DEFAULT '0' COMMENT '乐观锁版本号',
  PRIMARY KEY (`ID`),
  KEY `IDX_SPU_ID` (`SPU_ID`),
  KEY `IDX_SKU_ID` (`SKU_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品SKU库存表';

其他字段在实例中省略了。
我们看看如何使用这一张表满足上述要求：
1，检查库存是否够用：

STOCK_LEFT_NUM >= n

2，防止并发超卖：
利用数据库行级锁防并发

WHERE SKU_ID = ${sku_id}

3，锁库存：

STOCK_LOCK_NUM = STOCK_LOCK_NUM + n

那么，具体的下单、取消订单、支付等业务节点就可以如下实现：
1，下单

UPDATE `goods_stock`
  SET `STOCK_LOCK_NUM` = `STOCK_LOCK_NUM` + ${lockNum}
  WHERE `STOCK_LEFT_NUM` <![CDATA[ >= ]]> ${lockNum}
    AND `SKU_ID` = ${skuId}
    AND ${lockNum} <![CDATA[ > ]]> 0

当该操作执行成功，再处理其他逻辑；如果失败，就直接返回下单失败。
2，取消订单

UPDATE `goods_stock`
  SET `STOCK_LOCK_NUM` = `STOCK_LOCK_NUM` - ${lockNum}
  WHERE `SKU_ID` = ${skuId}
    AND ${lockNum} <![CDATA[ > ]]> 0

3，支付订单

UPDATE `goods_stock`
  SET `STOCK_LOCK_NUM` = `STOCK_LOCK_NUM` - ${lockNum},
      `STOCK_SALE_NUM` = `STOCK_SALE_NUM` + ${lockNum},
      `STOCK_LEFT_NUM` = `STOCK_LEFT_NUM` - ${lockNum}
  WHERE `STOCK_LOCK_NUM` <![CDATA[ >= ]]> ${lockNum}
    AND `SKU_ID` = ${skuId}
    AND ${lockNum} <![CDATA[ > ]]> 0

目前MySql+SD硬盘的话，MySql事务并发量达到2000是没啥压力的，所以一般并发2000左右的都可以直接使用MySql数据库设计业务逻辑，无需使用Redis缓存。
这里只是给出了商品库存核心逻辑，券和其类似，不过还多一点库存池（存放券码），其实这个可以放到后台去处理了；红包比这个更简单，只有下单（领红包）操作。

共同学习QQ群：793305035