分布式秒杀系统-REDIS（高并发、高性能、库存数据一致、非阻塞拒绝模式、不限语言-设计思路一致）

一、秒杀系统准备（基础设施）

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、所以最终的负载消耗，请以自己的服务器架构配置为准即可。也就是说本方案仅需要去关注服务器环境的压力支撑，不需要刻意关注系统。

最后编辑于：2018.12.10 12:27:50