直降公益活动是指互联网店家为打折等目地组织或网路上COMPILATION热卖公益活动，此种公益活动具有脉动mammalian量大、库存量少和业务逻辑简单等特征。设计一个直降系统需要考虑的因素许多，比如说对原有业务的影响、互联网频宽耗用和超买等因素。本文会探讨直降系统的全过程可能将存在的问题和解决计划。

直降系统

破密直降系统

直降系统的核心症结是mammalian量，如果不考虑mammalian问题，那么他们能用如下表所示图右图的简单的系统结构来实现直降系统，用户多于三个简单操作：创下介面和直降按键，服务端也多于三个服务USB：回到直降介面和处理直降逻辑。假设本文中直降货品有100个，参予直降的用户有100w个。

但是在高mammalian情景下，这个系统会有许多问题，他们概要会特别针对那些问题——展开优化

1.大批用户与此同时创下介面，会对服务器的频宽导致十分大的阻力；

2.用户在直降其间能若干次点选按键，导致许多不必要性的允诺；

3.用户能透过JAVA展开热卖，因此热卖成功率十分高；

4.服务端忍受高mammalian允诺，会再次出现积极响应太慢或失利等情况；

5.数据库忍受高mammalian允诺，会导致连接池用尽和积极响应较慢；

6.如果数据库预览设计得不科学合理，可能将会再次出现超买的情况；

直降介面CDN

直降已经开始以后，用户单厢允诺直降介面，有的是用户即使会不断地创下直降介面，100W用户可能将产生上亿次直降介面允诺。直降介面常常包涵许多动态资源，如果那些介面允诺全部透过服务器获取，会导致大批的频宽耗用，即使导致直降还没已经开始服务器就崩了的情况。对于页面此种动态资源的mammalian出访，业界早已有成熟的解决计划：内容递送互联网(CDN)。他们能在直降已经开始前，事先把页面的动态资源存放在CDN节点，用户在创下介面时直接从CDN获取动态资源，从而减少创下直降介直面服务器导致的阻力。加进了CDN服务之后，直降介面有大批用户与此同时出访和创下并不会给服务端带来数不清阻力。

直降按键优化

他们知道，直降系统常常会有一个直降按键，如果不对按键展开限制，可能将存在以下问题：用户在直降已经开始前点选按键，导致许多无用的允诺；用户在直降已经开始后多次点选按键，导致许多重复允诺；所以他们能对按键做一些限制：直降已经开始前按键不可用，用户点选一次直降按键后，按键也进入不可用状态。此种方式无法限制透过JAVA允诺后端的情况，但是能限制正常用户的多次无效点选，大大减少允诺量。

直降链接优化

普通情况下，用户在点选直降按键的时候，前端会允诺一个固定的URL，这个URL能在前端介面查到。对于普通不懂技术的用户来说，这没有什么问题，如果用户稍微懂点Http协议，就能在直降已经开始前拿到URL，在直降已经开始前或已经开始的毫秒级时间内允诺直降链接，不仅会给服务端带来很大的阻力，还会导致不公平现象：货品都被开JAVA的人抢走了。

为了避免此种现象，他们能将URL动态化，即使直降系统的开发人员也无法在知晓在直降已经开始时的URL。具体实现方法是在获取直降URL的USB中，回到一个服务器端生成的随机数，并在下单URL中传递该参数完成下单。

直降验证码

虽然说我上面透过动态URL避免了用户在直降已经开始前允诺直降链接，但是用户还是能透过JAVA在直降已经开始的那一刻去允诺直降连接，普通用户基本没有办法和JAVA直降展开竞争。他们能引入机器难以识别的验证码，用户在允诺直降链接以后，需要填写验证码识别的结果，验证码错误的允诺直接拒绝。使用验证码不仅能增加JAVA直降的难度，还能减少允诺的QPS，因为允诺不再是在直降那一刻进来，而会被分散到填写验证码的时间段内。

过滤允诺

透过上面的步骤，他们能减少许多重复允诺和JAVA允诺，能保证直降公益活动中一个人大致只会允诺一次(JAVA还是能允诺多次)。但是100W人参予直降，每人允诺一次直降链接也有将近100W次允诺，服务器还是扛不住。仔细分析之后能发现，直降的货品多于100个，最后成功的也多于100个，那么他们100W的允诺是不是都有必要性允诺到直降服务器上呢？显而易见，他们没有必要性把所有请求都打到直降服务器上，他们只需要保证有大于100个允诺打到直降服务器就能保证直降的正常展开，所以他们能在用户端和服务端加进一层过滤层，过滤层只要保证有100个以上的允诺能打到直降服务器端。

他们能使用Nginx服务器来构建过滤层，一个Nginx服务器也没法抗100W的允诺，他们假设每个Nginx服务器能处理10W的允诺，那么他们就需要10台Nginx。那么怎么用保证至少有100个允诺能允诺到后端呢?他们能简单的让每个Nginx服务器只透过前100个允诺，后续允诺直接回到降级介面。透过Nginx过滤，他们能把100W的允诺过滤为1000个允诺，大大减少了服务器端的阻力。

Redis缓存

如果透过前面的过滤，允诺量依旧十分大，如果数据库无法处理那些允诺量，他们就需要在数据库之上加进一层Redis缓存了。单个Redis能处理几万的QPS，如果预估允诺的QPS大于几万，他们还能使用Redis集群模式来增加Redis的处理能力。

在Redis存放和售卖货品数目大小相同的数字，直降服务每次出访数据库以后，都需要先去Redis中扣减库存，扣减成功才能继续预览数据库。这样，最终到的数据库的允诺数目和需要售卖货品的数目基本一致，数据库的阻力能大大减少。

Redis原子性

他们知道Redis是不支持事务的，所以可能将再次出现扣减为负数的情况，此种情况下他们能使用LuaJAVA来保证一次扣减操作的原子性，从而保证扣减结果的正确性。

异步预览数据库

透过Redis判断之后，去预览数据库的允诺都是必要性的允诺，那些允诺数据库必须要处理，但是如果数据库还是处理不过来那些允诺怎么办呢？

这个时候就能考虑削峰填谷操作了，削峰填谷最好的实践就是MQ了。经过Redis库存扣减判断之后，他们已经确保这次允诺需要生成订单，他们就能透过异步的形式通知订单服务生成订单并扣减库存。