竞拍系统设计（秒杀系统知识迁移）

作者：sengerlion

来源：SegmentFault 思否社区

自从上次整理了秒杀系统的文章（php+golang商品秒杀）后，知识迁移一新项目，商品竞拍。

技术：php、mysql、redis、laravel

业务对象：商品、场次、订单

竞拍过程：

一、实现商品、竞拍场次和订单的CRUD;
二、定时将秒杀场次、商品、库存等信息提前写入redis；
三、配置Redis持久化；
四、实现秒杀下单逻辑；
五、秒杀过程redis优化；
六、使用golang并发编程模拟秒杀。

一、实现商品、竞拍场次和订单的CRUD;

商品表：

 CREATE TABLE `goods` (
  `id` int(12) unsigned NOT NULL AUTO_INCREMENT COMMENT 'pk',
  `num` varchar(64) NOT NULL COMMENT '商品编号',
  `users_id` int(12) unsigned NOT NULL COMMENT '拥有者',
  `create_users_id` int(12) unsigned NOT NULL COMMENT '商品创建人',
  `contract_roles_id` int(10) unsigned NOT NULL COMMENT '商品合约级别外键',
  `name` varchar(255) NOT NULL COMMENT '商品名称',
  `img` int(11) NOT NULL COMMENT '封面图',
  `price` decimal(10,2) unsigned NOT NULL COMMENT '当前价格',
  `area_id` int(11) NOT NULL COMMENT '区域id',
  `trade_num` int(11) unsigned NOT NULL COMMENT '交易次数',
  `user_name` varchar(100) DEFAULT NULL COMMENT '收货人名称',
  `user_phone` varchar(11) DEFAULT NULL COMMENT '收货人联系电话',
  `user_address` varchar(255) DEFAULT NULL COMMENT '收货人地址',
  `express_id` int(11) DEFAULT NULL COMMENT '物流ID',
  `express_no` varchar(255) DEFAULT NULL COMMENT '物流单号',
  `is_auction` tinyint(1) NOT NULL DEFAULT '1' COMMENT '是否可竞拍，1=》可 2=》不可',
  `status` tinyint(1) unsigned NOT NULL DEFAULT '1' COMMENT '状态1=>可交易 2=>待支付 3=>交易完成 4=>待发货 5=》配送中 6=>完成 7 =>待收款',
  `next_time` timestamp NULL DEFAULT NULL COMMENT '下次最早显示时间',
  `trade_time` timestamp NULL DEFAULT NULL COMMENT '下次可交易时间',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT NULL COMMENT '更新时间',
  `deleted_at` timestamp NULL DEFAULT NULL COMMENT '删除时间',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=111 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

竞拍场次表：

CREATE TABLE `auctions` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `area` tinyint(4) NOT NULL COMMENT '拍卖区域，1=>新手区，2=>竞拍区，3=>星级区',
  `name` varchar(64) DEFAULT NULL COMMENT '场次名称',
  `start` time NOT NULL COMMENT '开始时间',
  `end` time NOT NULL COMMENT '结束时间',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT NULL COMMENT '更新时间',
  `deleted_at` timestamp NULL DEFAULT NULL COMMENT '删除时间',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='拍卖场次表';

订单表：

CREATE TABLE `orders` (
  `id` int(12) unsigned NOT NULL AUTO_INCREMENT COMMENT 'pk',
  `serial_num` varchar(32) DEFAULT NULL COMMENT '流水号，没交易前为空',
  `goods_id` int(12) unsigned NOT NULL COMMENT '商品id',
  `sell_users_id` int(12) unsigned NOT NULL COMMENT '竞拍商品拥有者id',
  `buy_users_id` int(12) unsigned DEFAULT NULL COMMENT '购买商品用户id',
  `buy_price` decimal(10,2) NOT NULL COMMENT '购买价格-成本价格',
  `pay_time` datetime DEFAULT NULL COMMENT '支付时间',
  `status` char(5) NOT NULL COMMENT '状态10000=>待支付  20000=>支付超时 30000=>确认支付 30001=>确认收款 40000=>卖家申诉中 40001=>买家申诉中 45000=>申诉完成 50000=>完成',
  `contract_roles_id` int(10) NOT NULL COMMENT '购买时商品合约外键',
  `charge_rate` decimal(10,4) unsigned DEFAULT NULL COMMENT '手续费',
  `remark` varchar(255) DEFAULT NULL COMMENT '备注-可以填写申诉结果',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT NULL COMMENT '更新时间',
  `deleted_at` timestamp NULL DEFAULT NULL COMMENT '删除时间',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

二、定时提前写入redis

1、竞拍场次时间是为每天固定的三个时间，定时提前写入并设置过期时间。

2、缓存数据结构设计有两个版本：

a、第一个版本的数据结构设计在商品列表查询时，无法排除自身商品信息并且分页。

• 不同区域可秒杀的用户set (判断用户所属竞拍区)

    key: prefix + area_id + start + end + auctions_id, 
    value:uid
  

• 不同区域下的商品信息zset (可支持分页)

    key: prefix + area_id + start + end + auctions_id, 
    score:goods_id, 
    member:goods_detail
  

• 库存字面量

  key: random  
  value:1 
  

• 是否购买占位

  key: prefix + area_id + start + end  
  value:1 
  

为了满足排除自身的商品功能和分页，思考了一些实现方案:

（1） 完全放弃从缓存中获取竞拍商品信息，这样增加数据库压力，同时无法使用竞拍随机码。
（2）为每个用户单独存放一个排除自身商品信息的集合，这样会存放重复数据造成增加内容空间。
（3）查询到redis有一个SCAN命令来迭代获取数据，并可利用glob模式匹配，但是获取数量无法确定而无法分页。

以上（1）（3）点都被排除，我们从第（2）出发重新设计第二版数据结构，单独存放商品数据和用户可查询的商品id集合来减少重复，但又会出现keys过多的情况，需要进行优化。

b.第二个版本的数据结构设计

• 用户可查询的商品id的zset (判断用户是否有可竞拍商品)

 key: prefix + area_id +users_id + auction_id+ start + end, 
 score:goods_id, 
 member:goods_id

• 商品信息string (可支持分页)

 key: prefix + area_id + auction_id + goods_id + start + end, 
 value:goods

• 库存字面量

 key: random  
 value:1 

• 是否购买占位

  key: prefix + area_id + start + end  
  value:1 

图片请参考另外一篇文章：

https://segmentfault.com/a/1190000039349297