秒杀器

如果你看过秒杀系统的流量监控图的话，你会发现它是一条直线，就在秒杀开始的那一秒是一条很直很直的直线，这时因为秒杀请求在时间上高度集中于某一个特定的时间点。这样一来，就会导致一个特别高的流量峰值，它对资源的消耗是瞬时的。 对于秒杀这个场景来说，最终能够抢购到商品的人数是固定的。也就是说，100个人和1000000个人发起请求的结果都是一样的，最后都只会有100个人买到秒杀的商品。这就意味着，并发量越高，最终的无效请求也就越多。 但是对于业务来说，秒杀活动本身是一种商业推广行为，肯定是希望有更多的人参与进来的。无效的请求越多，也就表示这商业推广越成功。只是在秒杀开始的时候，这些大量的秒杀请求就会给承载秒杀的服务器带来沉重的负担，因此我们可以设计一些规则，让并发的请求延缓或过滤掉这些无效请求，以此来削弱流量高峰对服务器的压力，这就是流量削峰。 为什么要削峰 我们知道，服务器的处理资源是恒定的，你用或者不用，它就在原地，处理能力不会改变。所以出现峰值的话，就很容易会导致忙到处理不过来，虽然闲的时候也会没什么要处理。但是为了保证服务质量，很多处理资源只能够按照忙的时候来预估，而这样就会导致资源的浪费。 流量削峰就好比因为存在早高峰和晚高峰的问题，所以有了错峰限行的解决方案。 削峰的存在，一是可以让服务端处理变得平稳，二是可以节省服务器的资源成本。 针对秒杀这一场景

#一些数据# 大家还记得2013年的小米秒杀吗？三款小米手机各11万台开卖，走的都是大秒系统，3分钟后成为双十一第一家也是最快破亿的旗舰店。经过日志统计，前端系统双11峰值有效请求约60w以上的QPS ，而后端cache的集群峰值近2000w/s、单机也近30w/s，但到真正的写时流量要小很多了，当时最高下单减库存tps是红米创造，达到1500/s。 #热点隔离# 秒杀系统设计的第一个原则就是将这种热点数据隔离出来 ，不要让1%的请求影响到另外的99%，隔离出来后也更方便对这1%的请求做针对性优化。针对秒杀我们做了多个层次的隔离： 业务隔离 。把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就是已知热点，当真正开始时我们可以提前做好预热。 系统隔离 。系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外99%分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中。 数据隔离 。秒杀所调用的数据大部分都是热数据，比如会启用单独cache集群或MySQL数据库来放热点数据，目前也是不想0.01%的数据影响另外99.99%。 当然实现隔离很有多办法，如可以按照用户来区分，给不同用户分配不同cookie，在接入层路由到不同服务接口中；还有在接入层可以对URL的不同Path来设置限流策略等。服务层通过调用不同的服务接口