如何实现“秒杀”系统

1） 对现有网站业务的冲击

因为秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。

2） 高并发情况以及数据库的负载

用户在秒杀开始前，通过不停的刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器、数据库服务器造成极大的负载压力。

3） 突然增加的网络和服务器带宽

假设商品页面大小200K（主要是商品大小），那么需要的网络和服务器带宽是2G（200K×10,000），这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。

4） 直接下单

秒杀的游戏规则是到了秒杀时间才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的URL，如果得到这个URL，不用等到秒杀开始就可以下单了。

5） 防止机器秒杀

防止网上的一些“秒杀器”

针对上面的5个问题，对应的策略如下：

1） 秒杀系统独立部署

为了避免因为秒杀活动的高并发访问而拖垮整个网站，使整个网站不必面对蜂拥而来的用户访问，将秒杀系统独立部署，如果需要，还可以使用独立的域名，以和网站完全隔离，即使秒杀系统崩溃了，也不会对网站造成任何影响。

2） 秒杀商品页面静态化

秒杀商品页面重新设计，不使用网站原来的商品详情页面，页面内容静态化：商品描述，商品参数，成交记录，用户评价全部写入一个静态页面，用户请求不需要经过应用服务器的业务逻辑处理，也不需要访问数据库。所以秒杀商品服务不需要部署动态的Web服务器、数据库服务器。

3） 租借秒杀活动网络带宽

对于因为秒杀新增的网络带宽，必须和运营商重新购买或者租借。为了减轻网站服务器的压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新增的出口带宽。

4） 动态生成随机下单页面URL

为了避免用户直接访问下单页面URL，需要将该URL动态化，即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的URL。办法是在下单页面URL加入由服务器端生成的随机数作为参数，在秒杀开始的时候才能得到。

5） 防止“秒杀器”感觉很难，

因为似乎总是有办法可以跳过设置的“障碍”。真正做到防止，仅靠webserver怕是很难防范，一般的做法都是增加一些人为的“障碍”，比如：

注册时有一定的门槛，像皮皮书屋一样，通过输入程序执行结果作为验证 –à之前批量手工注册

参加秒杀的积分或者等级策略 -à 挂太阳，就如同你当你为了升级QQ等级的时候一直挂着QQ一样。

验证码，阻止自动化操作 -à 可以图像识别

ip阻止 –à 但是ip可以伪造,可以代理

这类活动很大一部分都有内幕的，特别是一些中小型的商家。当然如果是大型商家的活动，即使没内幕，抢的人多，数量就那么点，很难抢到的，除了网速跟电脑配置稍微影响点，完全拼人品。

淘宝程序会限制一些，短时间不断请求的用户，会出现‘哎哟喂，被挤爆啦，请稍后重试’的代码，大概5～10分钟会自动解除，应该限制的是IP，所以抢购的时候，提前30秒左右刷几下就可以了。

扩展资料：

秒杀是成功是比较难的，就像11月11日淘宝做活动，好多东西秒杀，秒杀了5次都没成功，不过点了“立即购买”后，能进到下一个界面，但是后一步就不成功了。

淘宝上秒杀价一是看运气，二是看网速，三是看手速。不过一般都是抢不到的，水手太多了，敌不过的。不过你可以尝试别的商品抢购，限购份数比较多的那些商品。

“按秒计费”是目前公有云的优势所在。为什么这么说呢？

众所周知，公有云是互联网被服务提供商提供的，区别于私有云，公有云云服务器是从物理服务器上虚拟出来的，它拥有物理服务器所有的资源，用户可以使用它来搭建应用程序或者存储数据，就像物理服务器一样。但区别在于云服务器更便宜，最适合普通用户，因为带宽，应用程序和硬件成本都由供应商承担，所以建立起来并不昂贵，而使用成本则取决于用户使用的容量。

也就是说云服务器可以实现按量付费。

按秒计费正是基于此。用户按量付费资源从创建开始计费，到释放结束计费，精确到秒。

按秒计费适用于某些弹性应用场景，比如秒杀、明星绯闻曝光等场景，高峰过后释放，这种场景下，更细粒度的计费模型，能让企业有能力用更低的成本处理访问量暴增的情况。

大概思路吧：

秒杀系统的架构设计

秒杀系统，是典型的短时大量突发访问类问题。对这类问题，有三种优化性能的思路： 

写入内存而不是写入硬盘 

异步处理而不是同步处理 

分布式处理 

用上这三招，不论秒杀时负载多大，都能轻松应对。更好的是，Redis能够满足上述三点。因此，用Redis就能轻松实现秒杀系统。 

用我这个方案，无论是电商平台特价秒杀，12306火车票秒杀，都不是事:)

下面介绍一下为什么上述三种性能优化思路能够解决秒杀系统的性能问题：

写入内存而不是写入硬盘 

传统硬盘的读写性能是相当差的。SSD硬盘比传统硬盘快100倍。而内存又比SSD硬盘快10倍以上。因此，写入内存而不是写入硬盘，就能使系统的能力提升上千倍。也就是说，原来你的秒杀系统可能需要1000台服务器支撑，现在1台服务器就可以扛住了。 

你可能会有这样的疑问：写入内存而不是持久化，那么如果此时计算机宕机了，那么写入的数据不就全部丢失了吗？如果你就这么倒霉碰到服务器宕机，那你就没秒到了，有什么大不了？ 

最后，后面真正处理秒杀订单时，我们会把信息持久化到硬盘中。因此不会丢失关键数据。 

Redis是一个缓存系统，数据写入内存后就返回给客户端了，能够支持这个特性。

异步处理而不是同步处理 

像秒杀这样短时大并发的系统，在性能负载上有一个明显的波峰和长期的波谷。为了应对相当短时间的大并发而准备大量服务器来应对，在经济上是相当不合算的。 

因此，对付秒杀类需求，就应该化同步为异步。用户请求写入内存后立刻返回。后台启动多个线程从内存池中异步读取数据，进行处理。如用户请求可能是1秒钟内进入的，系统实际处理完成可能花30分钟。那么一台服务器在异步情况下其处理能力大于同步情况下1800多倍！ 

异步处理，通常用MQ(消息队列)来实现。Redis可以看作是一个高性能的MQ。因为它的数据读写都发生在内存中。

分布式处理 

好吧。也许你的客户很多，秒杀系统即使用了上面两招，还是捉襟见肘。没关系，我们还有大招：分布式处理。如果一台服务器撑不住秒杀系统，那么就多用几台服务器。10台不行，就上100台。分布式处理，就是把海量用户的请求分散到多个服务器上。一般使用hash实现均匀分布。 

这类系统在大数据云计算时代的今天已经有很多了。无非是用Paxos算法和Hash Ring实现的。 

Redis Cluster正是这样一个分布式的产品。

使用Redis实现描述系统

Redis和Redis Cluster（分布式版本），是一个分布式缓存系统。其支持多种数据结构，也支持MQ。Redis在性能上做了大量优化。因此使用Redis或者Redis Cluster就可以轻松实现一个强大的秒杀系统。 

基本上，你用Redis的这些命令就可以了。 

RPUSH key value 

插入秒杀请求

当插入的秒杀请求数达到上限时，停止所有后续插入。 

后台启动多个工作线程，使用 

LPOP key 

读取秒杀成功者的用户id，进行后续处理。 

或者使用LRANGE key start end命令读取秒杀成功者的用户id，进行后续处理。 

每完成一条秒杀记录的处理，就执行INCR key_num。一旦所有库存处理完毕，就结束该商品的本次秒杀，关闭工作线程，也不再接收秒杀请求。

要是还撑不住，该怎么办

也许你会说，我们的客户很多。即使部署了Redis Cluster，仍然撑不住。那该怎么办呢？ 

记得某个伟人曾经说过：办法总比困难多！

下面，我们具体分析下，还有哪些情况会压垮我们架构在Redis（Cluster）上的秒杀系统。

脚本攻击

如现在有很多抢火车票的软件。它们会自动发起http请求。一个客户端一秒会发起很多次请求。如果有很多用户使用了这样的软件，就可能会直接把我们的交换机给压垮了。

这个问题其实属于网络问题的范畴，和我们的秒杀系统不在一个层面上。因此不应该由我们来解决。很多交换机都有防止一个源IP发起过多请求的功能。开源软件也有不少能实现这点。如linux上的TC可以控制。流行的Web服务器Nginx（它也可以看做是一个七层软交换机）也可以通过配置做到这一点。一个IP，一秒钟我就允许你访问我2次，其他软件包直接给你丢了，你还能压垮我吗？

交换机撑不住了

可能你们的客户并发访问量实在太大了，交换机都撑不住了。 

这也有办法。我们可以用多个交换机为我们的秒杀系统服务。 

原理就是DNS可以对一个域名返回多个IP，并且对不同的源IP，同一个域名返回不同的IP。如网通用户访问，就返回一个网通机房的IP；电信用户访问，就返回一个电信机房的IP。也就是用CDN了！ 

我们可以部署多台交换机为不同的用户服务。 用户通过这些交换机访问后面数据中心的Redis Cluster进行秒杀作业。

总结

有了Redis Cluster的帮助，做个支持海量用户的秒杀系统其实So Easy！ 

这里介绍的方案虽然是针对秒杀系统的，但其背后的原理对其他高并发系统一样有效。 

最后，我们再重温一下高性能系统的优化原则： 

写入内存而不是写入硬盘 

异步处理而不是同步处理 

分布式处理

大家都知道，只要我们讨论到电商平台，那自然少不了商品秒杀的话题，而且如果去电商类互联网公司面试，那面试官肯定也会问你如何实现商品秒杀系统的架构设计。可能有很多人不屑一顾，商品再怎么秒杀，不就是一群人抢数量有限的商品吗？有什么难的？

其实我要说的是，对于小型电商平台而言实现商品秒杀感觉的确很简单，但对于像淘宝这类的电商巨头平台而言，商品秒杀系统的设计真的很不简单，要考虑的事项太多。

秒杀系统的本质及常见问题

所谓商品秒杀，说得通俗点就是一大群人在短时间内去抢购为数不多的商品。听上去很简单，但是对于流量较大的电商平台而言，商品秒杀系统如果设计得不好，会出很大问题的，比如：

1、对网站现有业务会造成冲击

秒杀活动是一种营销手段，这会导致在某一刻会吸引很多人来抢购，并发量过大会对现有业务造成冲击，甚至可能导致网站瘫痪。所以像之前的小米发布新品，很多人连登录都登录不上就是这个原因。

2、服务器带宽洪峰

商品秒杀页一般都会设计得比较个性，所以资源也较多，在高并发场景下会导致服务器流量突增，所以要考虑服务器的带宽是否足够。

3、服务器及数据库负载过高

相信大家都参加过秒杀活动，回顾一下，我们是不是在秒杀活动开始前习惯性的一直刷新页面很多用户都是这样，一直刷新页面，这样就变相的增加服务器及数据库的负载。

4、防止机器提交下单请求

这一点尤为重要，就像一些刷票软件一样，有人为了能秒杀到商品会利用机器进行秒杀，机器发出的请求比人为发出请求总是要快一步的。

5、成功秒杀了，但商品数量却不够

如果是这种情况，那估计就会受到投诉了，明明提示我秒杀成功了，但商品数量却显示0，这种逻辑错误不能犯。

秒杀系统该如何设计？

其实秒杀系统的核心问题是全局性和原子性操作，另外还要考虑到高并发带来的冲击。结合我的开发经验，给出一些设计方案供大家参考：

1、秒杀系统设计的思路

一定要用到队列（可以理解为“排队”机制），当秒杀活动开始后，所有的请求往这个队列里放，另外这个队列长度是有限制的（队列长度就是商品数量），当队列数达到后，活动页面就提示活动结束，然后队列里的请求再去进行下一步处理。

2、秒杀系统独立部署

为避免秒杀活动给现有业务带来冲击，我们建议秒杀系统单独部署（独立域名+服务器）这样即使秒杀系统瘫痪了也不会影响现有电商业务的运行。

3、活动页静态化+CDN加速

为减小系统负载、加快页面打开速度，我们建议活动页面要静态化处理（这样比动态页面性能要好），再走CDN加速，这样能保证多数用户访问活动页的速度都是很快的，不会卡顿。

4、下单页URL动态生成

为防止机器下单和提前下单，下单页的URL要动态生成，不能固定不变的。

5、服务降级

在双11期间，我们会发现淘宝及支付宝很多不重要的功能都是禁用的，这就是服务降级。服务降级是指停止一些不重要的服务，将资源让给秒杀系统，以提高其负载能力。

秒杀跳转软件提前几秒的原因是为了在秒杀开始时，能够在最短时间内抢到心仪的商品。通过提前几秒跳转到商品页面，可以在秒杀开始时立即点击购买，从而提高成功抢购的概率。

然而，使用秒杀跳转软件提前几秒抢购也存在一些风险和不利因素。首先，使用软件可能会违反电商平台的规定，导致账号被封禁或商品交易被取消。其次，即使使用了秒杀跳转软件，也不能100%保证成功抢购，因为抢购的成功率还受到网络延迟和抢购人数等因素的影响。此外，使用软件抢购也可能会对其他消费者造成不公平的竞争，影响消费市场的公平性和正常秩序。因此，消费者在抢购时应该遵守平台规定，保持理性和公平，不要使用违法违规的方式抢购商品。