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

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

前端

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

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

比如，对需要输入手机号的秒杀抢券活动来说，为了避免掉恶意请求，尽量在前端添加手机号合法性的验证。当然，随着手机号的不断增多，现在已经出现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 压力。

经过这样的设计，最终真正访问数据库的有效请求只有最大库存数量一样多，每一个访问数据库的请求都应当返回一个券码，做到了弹无虚发。