一、秒杀系统准备（基础设施）
1、能够抗住基本请求流量的服务器环境(如：nginx集群+tomcat集群)
2、高可用的redis环境（redis如果达到瓶颈，首先很难，那么可以一个商品ID走一个reids即可)
3、写代码的小哥哥
二、代码结构
1、redisKey准备【时间复杂度均为O(1)】
(1：秒杀用户操作锁 （参考：http://redisdoc.com/string/set.html 末尾）
命令：SET resource-name anystring NX EX max-lock-time
解锁：if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end
key： FLASH_LOCK
内容：{userId}
(2：秒杀库存（参考：http://redisdoc.com/string/incr.html）
命令：incr \ INCRBY
key： FLASH_COUNT
内容：{日期_场次_商品ID}
优点：即使秒杀开始，用户数量N在微秒级同一时间get库存均为N1还有库存，也不会阻塞N中的其他用户，除非N中的某个用户碰巧库存全部消耗，被拒绝。否则，所有用户均能成功
2、API-秒杀数据查询接口
获取配置：场次、开始时间点、结束时间点、商品list{id,name,资格(如积分),总库存} ，
注意：如果没有配置中心或者动态配置需要放在数据库的话，禁止每次走DB查询，善用缓存
配置计算：计算当前场次，返回商品列表，返回商品剩余库存(总库存-FLASH_COUNT )
额外优化：
(1、本接口可加入应用内存缓存模式，场次开始前1分钟走内存，即将开始才走实时REDIS查询剩余库存
(2、也可以走预生成配置模式，将计算好的逻辑放到REDIS中，接口仅仅做实时库存查询
3、API-秒杀接口(接口响应时间：除开框架的基本消耗约1~2毫秒)
（1、用户授权、基本参数验证（一般在框架中）
（2、本场本商品ID是否已经没有了库存（单商品应用内存锁定，立即减少redis get压力）【没有库存立即响应结果】
（3、获取用户操作锁FLASH_LOCK 【失败立即响应，操作进行中】
getLock -》try {代码}catch (XX) {日志}finally {解锁}
（4、场次开始、商品有效等基本判定【失败立即响应】
(5、立即redis get FLASH_COUNT 验证商品是否有库存【没有库存立即响应结果，写入单商品应用内存锁定】
(6、验证用户资格（如积分是否充足）【没有余额立即响应结果】
（7、开始秒杀 incr FLASH_COUNT 【验证获取到的序列是否超过库存，步骤5微秒级同时get到会进入7被最终拦截，如果超过则响应没有库存了，写入单商品应用内存锁定】
(8、最终的幸运儿下单、落库、走各自的奖励发放流程(可同步，可异步计入中奖队列)
PS：
1、如果你的每秒请求只有几百几千一个REDIS完全够用不需要额外操心，另外秒杀功能产品往往会加一个小梗，那就是开始秒杀时用户需要填写兑换的账号才能发起秒杀，这里根据用户的操作时间本质上又做了一次/n的分流。其次前端本身还会验证用户是否有资格参与秒杀（余额预验证）。所以也就是说一场活动可能有10万人参与，但是有资格的可能只有1万人，再加操作时间线控制，真实并发最多几千。一台NGINX，一台REDIS完全够了。
2、经过测试多节点高并发压力测试
除能够抢到的用户(会真实落库或计入中奖队列)，其他被拒绝的用户：tomcat接口请求响应速度和正常的一个无任何逻辑的接口响应时间误差1毫秒左右，比如你一个API没有任何处理：逻辑框架的响应时间为1~2毫秒。那么秒杀接口响应大约在2~3毫秒
redis CPU负载基本忽略不计
3、所以最终的负载消耗，请以自己的服务器架构配置为准即可。也就是说 本方案仅需要去关注服务器环境的压力支撑，不需要刻意关注系统。
网友评论