一、秒杀系统准备(基础设施)

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

文章来源于互联网:分布式秒杀系统-REDIS(高并发、高性能、库存数据一致、非阻塞拒绝模式、不限语言-设计思路一致)

发表评论