电商秒杀基本原理：

 请求接口的设计
秒杀分为两个部分，一个是页面，一个是web后台。一般页面的访问压力不大，主要是后台的并发请求的压力。能够实现短时间处理大量的请求。
基于这种需求，把后端存储改为内存存储比较好。
用户通过页面发秒杀起求。进行负载均衡。请求到了web服务器，通过redis进行缓存。其他的操作同步异步来处理。
（也可以设计为滞后响应。过一段时间才能看到结果。但是这种效果反馈并不好，有暗箱操作的嫌疑）
 高并发情况分析
秒杀服务器最重要的指标就是每秒处理请求数。
按达到并发的数目为5万的话。假设每个请求处理时间为100ms，系统有20台apache服务器。每台最大连接数目为500。
这样理论上一秒处理的请求应该就是10万的。应该能够满足需求。
但是，实际场景中，机器处于高负载状态，平均响应时间会变长。假设100ms的响应时间变为250ms，再重新进行计算的话就会发现，变成了4万的并发。差1万。达不到了需求。这样在满负载读状态下还有1万的并发无法处理。这是系统就会出现问题。
可以增加服务器来解决，但是服务器并不是越多越好。有一个最适合的值。能够通过测试得到。
在系统无法响应的时候，用户一般会点击更加频繁。是系统最终崩溃。重启也无法解决问题。
这是可以进行过载保护，当系统达到满负载状态时，拒绝用用户的访问，但是这样应并不好。
另一种解决途径就是控制访问量。
 访问量控制。
在秒杀过程中如此大的并发访问里面的水分很大。有人用秒杀工具帮助。或是写自动请求脚本。应该把这部分控制好。有几种情况：

1. 同一账号，一次性发多次请求。
   可以使用判断条件进行过滤，判断用户是否有参与记录。如果有秒杀失败，如果没有可以进行秒杀，存入参与记录中。但是这种会有问题，当一起请求多个。会有请求响应时间差。存在逻辑判断被绕开的风险。
   一般在程序入口处，一个账户只接受一个请求，其他的请求过滤掉。
   还可以使用队列，将一个账户的请求放入同一个队列之中。处理完一个再处理下一个。
2. 多个账号，一次性发多次请求。
   很多使用僵尸号进行请求。
   这种可以通过检测指定ip请求频率就可以解决。如果发现某个ip请求频率高。可以弹出验证码或是直接禁止请求。
3. 多个账号，不同ip请求。
   这种情况和真实的用户区别不大，只能从业务层面来进行完善了，对账号数据进行挖掘，例如：要求用户资料信息完善，实名制。
    商品超发：
   例如有100件秒杀商品，只剩下最后一件的时候，高并发请求，在判断余量间隙时间里，其他请求可能进入。一件商品同时多人下单成功。
   解决方法：
   1、悲观锁思路：在修改数据的时候使用锁，排斥外部请求。虽然解决了问题，但是可能延长响应时间。导致服务器连接数耗尽，系统陷入异常。
   2、队列思路：使用队列，先进先出。但是会瞬间撑爆内存。队列处理请求速度赶不上新增请求的速度。平均响应时间会下降。
   3、乐观锁思路：采用带版本号更新。所有请求数据都会有资格去操作，但会获得一个该数据的版本号。只有版本号符合才会秒杀成功，否则失败。例如使用Redis中的watch