五、技术层面实现

这部分也是参考一些大神的博客得出的一些技术层面的心得，可能不是很恰当，希看大家指正。

1. 前端高并发

前端常用的方法是扩收留、静态化、限流。

扩收留：

加机器，这是最简单的方法，通过增加前端池的整体承载量来抗峰值。

举个通俗的例子：

比如我想运送100棵树木，我预备两辆卡车，一辆运50，计算公式就是2辆X50棵/辆X1小时=100棵/小时。

那假如我需要搬运更多的树木，我可以通过增加车辆、也可以增加每辆车的运输量、或者缩短运输时间。

这就是扩收留的概念。

静态化：

将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素，通过CDN来抗峰值。

限流：

一般都会采用IP级别的限流，即针对某一个IP，限制单位时间内发起请求数目；或者在活动进口，增加游戏或者题目环节进行消峰操纵。

有损服务：

最后一招，在接近前端池承载能力的水位上限的时候，随机拒尽部分请求来保护活动整体的可用性。

方案：本地标记+redis预处理+RabbitMQ异步下单+客户端轮询。

实现：

在秒杀阶段使用本地标记对用户秒杀过的商品做标记，若被标记过直接返回重复秒杀，未被标记才查询redis，通过本地标记来减少对redis的访问。
抢购开始前，将商品和库存数据同步到redis中，所有的抢购操纵都在redis中进行处理，通过Redis预减少库存减少数据库访问。
为了保护系统不受高流量的冲击而导致系统崩溃的题目，使用RabbitMQ用异队伍列处理下单，实际做了一层缓冲保护，做了一个窗口模型，窗口模型会实时的刷新用户秒杀的状态。
client端用js轮询一个接口，用来获取处理状态。