秒杀抢券系统实现的注意事项

忘是亡心i 2023-02-18 03:01 30阅读 0赞

秒杀抢券系统往往有一些需要注意的具体的地方，有接口安全方面的，也有数据库安全方面的，高并发方面的，这里主要从前后端两方面进行阐述。

## 前端 ##

**前端的一条原则：尽可能地保证发往后端的`数据`和`请求`是有效的。**  
具体措施如下：

*  添加手机号等账号的合法性验证
 *  秒杀请求携带接口签名
 *  点击秒杀按钮后置灰禁用

比如，对需要输入手机号的秒杀抢券活动来说，为了避免掉恶意请求，尽量在前端添加手机号合法性的验证。当然，随着手机号的不断增多，现在已经出现`19+`开头的号码，虽然前几年的验证方法很可能已经不适用于现在的实际情况，但是可以不用校验那么严格和具体。这样可以一定程度上保证`数据`的有效性。  
再比如，为了后端在一定程度上避免处理无效请求，在前端发送 *HTTP* 请求时，可以在请求头 Authorization 添加接口签名，签名值可以来源于时间等动态参数的简单加密。这样可以一定程度上保证`请求`的有效性。

## 后端 ##

**后端的一条原则：尽可能地保证有效的`请求`才能发往数据库。**  
具体措施如下：

*  验证接口签名，排除无效请求
 *  有参与资格的名单的话提前放到Redis
 *  活动的参与记录先保存到Redis
 *  Redis保存并分配券码自增序列id
 *  券码的总库存量提前记录到Redis

归根到底，秒杀抢券活动很多情况下都是抢一个券码，那我们肯定在数据库中提前准备了一个券码表，这个表至少必须有主键 id 和券码串 code 吧。所以其实秒杀的就是个`id`，买房摇号也是一样分配了一个自增的 id，若 id 在库存量之内就代表摇上了，稍微大一点代表还有机会，可以等前面的人放弃资格，若号码太靠后的话，就只存在理论上摇到的可能了。  
那么，这么重要的 id 选用`Redis`维护的原因是什么呢？

1.  Redis作为`分布式`NoSQL，便于后端秒杀服务节点的横向扩展，不用考虑跨JVM对id的分布式锁；
2.  Redis采用`内存`存储，性能够好，访问够快；
3.  Redis处理请求`单线程`，原子自增操作是线程安全的。

另外，Redis 除了维护自增 id 之外，也保存了参与资格名单、参与历史记录等，这一点主要考虑到Redis 可以帮助底层数据库做一层缓存，减少数据库 IO 压力。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw_size_16_color_FFFFFF_t_70_pic_center]  
经过这样的设计，最终真正访问数据库的有效`请求`只有最大库存数量一样多，每一个访问数据库的请求都应当返回一个券码，做到了弹无虚发。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200615161401529.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw==,size_16,color_FFFFFF,t_70#pic_center