只用数据库设计高效抢购业务

不使用缓存(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` = ]]> ${lockNum}
    AND `SKU_ID` = ${skuId}
    AND ${lockNum}  ]]> 0

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

UPDATE `goods_stock`
  SET `STOCK_LOCK_NUM` = `STOCK_LOCK_NUM` - ${lockNum}
  WHERE `SKU_ID` = ${skuId}
    AND ${lockNum}  ]]> 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` = ]]> ${lockNum}
    AND `SKU_ID` = ${skuId}
    AND ${lockNum}  ]]> 0

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

你可能感兴趣的:(只用数据库设计高效抢购业务)