程序员如何应对秒杀场景？

凡是做过电商的同学，都会遇到运营展开的秒杀，限时购等“高并发”的活动。
秒杀从规模上来说可以分为大秒和小秒。大秒指的是比如双11这种特定的节日，商品规模超大、价格超低、流量超大的这种类型活动，小秒一般指的是商家自己配置的一些时段类型的活动，由商家自己指定时间上架。从形式来说还可以分为单时段秒杀和多时段秒杀。但是在这个场景里，我们一般就是指的单时段大型秒杀。
秒杀这种业务场景其实特点很明显：
1、带有短期流量峰值特性，即：短时间内会有大量的请求涌入；
2、请求的数据带有热点性，即：大量的请求同一数据；
3、请求的成功有效率低，即：大量的请求中可能只有少量请求会成功处理业务；
4、请求的流量峰值发生在下单之前，即：付款阶段很少存在流量峰值。
一、秒杀的技术挑战
1、对现有网站业务造成冲击：秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪；
2、高并发下的应用、数据库负载：用户在秒杀活动开始之前，通过不停的刷新浏览器页面以保证不错过秒杀，这些请求如果按照一般网站的应用架构，访问应用服务器，连接数据库，会对应用服务器和数据库服务器造成极大的负载压力；
3、突然增加的网络及服务器带宽：因为访问秒杀页面的用户剧增，对资源的请求量也是剧增，网络带宽也上去了，超过平时网站使用的带宽；
4、直接下单：秒杀的规则是到了秒杀秒杀时间才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的URL，如果得到了这个URL，不用等到秒杀开始就可以下单了。
二、秒杀系统的应对策略
1、技术第一招：限流
对于秒杀出现的流量峰值，限流是最直接的削峰手段，被限制的请求可以直接返回，客户端提示请求中提示。可想而知，当10000/S的请求量被削成100/S的量，估计系统稍微优化一下就能抗住。
2、第二招：消息队列
说到消息队列，每个程序员都不陌生，它相当于一个快速的数据容器，可以作为一个缓冲层来应对流量高峰。如果从它的使用场景上来看，它可以算是低速设备和高速设备之间的平衡者，使用消息队列来进行削峰是一个很明显的异步流程。应用到秒杀的场景下，大量的请求会先进入消息队列，它不仅削平了流量的峰值，而且把秒杀下单的这个流程异步化，只要把请求都暂存入队列，消费端慢慢消费即可，但是这里要注意，如果消费的速度远远慢于消息的投递速度，可能会影响整个系统性能。
除了削峰之外，我始终认为消息队列的大作用是系统解耦，它把下单和支付解耦，下单和支付业务可以随着自身系统的承载量来单独扩容。
3、第三招：缓存
为什么要加入缓存这个选项呢？别忘了，除了大量的用户下单这个写操作之外，还有更大量的用户请求下单结果这个读操作。当用户点击秒杀按钮之后，系统会弹出等待的提示框，很多系统是不停的去轮训用户的下单结果，我之前也写过缓存的文章，曾经提到过缓存大的作用是提供读操作的快速响应。其实很多系统应用上消息队列+限流之后，针对秒杀业务已经足够了，其余的分库分表等方案可以根据自己的业务量来确定。每个系统在满足功能性的需求下，也在满足非功能性需求的前提下越简单越好，不是每个系统都需要淘宝的架构。
创新互联消息队列RabbitMQ是一款支持持久化消息队列的消息中间件。通过创建集群的方式来实现RabbitMQ以及所依赖的服务的部署，完全兼容RabbitMQ开源生态以及多语言客户端，为用户提供快速创建、方便管理的消息中间件。
创新互联消息队列RabbitMQ支持多种模式，满足不同使用场景，包括简单队列模式、work模式、发布/订阅模式、路由模式、topic模式等，提供CPU使用率、内存使用率、磁盘使用率、文件句柄使用数、Sockets句柄使用数等监控项，支持设置多项报警策略，帮助用户了解实例动态：
本文名称：程序员如何应对秒杀场景？
网页路径：http://cxhlcq.com/article/soccss.html