1. 举个例子，例如微博中有转发抽奖的活动，如果我们使用几万个“僵尸号”去混进去转发，这样就可以大大提升我们中奖的概率。
2）应对方案
1. 可以通过检测指定机器IP请求频率就可以解决，如果发现某个IP请求频率很高，可以给它弹出一个验证码或者直接禁止它的请求
3、多个账号，不同IP发送不同请求
1.8 高并发下的数据安全1、悲观锁思路
1. 悲观锁，也就是在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。
2. 然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。
3. 会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。
4. 同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。
2、FIFO队列思路
1. 我们直接将请求放入队列中的，采用FIFO（先进先出），这样的话，我们就不会导致某些请求永远获取不到锁。
2. 我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”。
3、乐观锁思路
1. 乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。
2. 实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。
3. 有很多软件和服务都“乐观锁”功能的支持，例如Redis中的watch就是其中之一。通过这个实现，我们保证了数据的安全。
1.9 真实案例讲解1、模块
1. 项目分成供应链和商城两大部分，供应链主要功能包括库存控制、商品信息录入、订单发货等；
2. 商城主要功能包括：商品搜索、秒杀、购买、支付、评论等；
3. 负责实现了购物车、支付、优惠券、秒杀等功能设计实现
2、主要技术点
1. 技术实现采用了RESTful设计，前后端分离；
2. 后端整体基于Python/Django + MySQL 开发，
3. 采用了 Redis 缓存，Celery 异步任务，ElasticSearch搜索；
4. 使用Docker部署交付；
3、秒杀系统设计
1.秒杀服务器部署与主站分离，防止整体宕机。
2.秒杀商品提前存入Redis List，size为秒杀数量。
3.在Nginx层 Web 层分别做限流，活动开始后，将用户购买请求放入RabbitMQ中排队，
消费者依次生成订单，同时减少Redis List中商品数量，并将生成的订单插入Redis和MySQL中供用户查询购买结果。
4.当商品数量为0时，剩余消息处理为抢购失败。
通过模拟测试，上述架构可支撑10w人抢购2000件商品的情景，并在60秒内处理完全部订单，
配置如下：在 aws 上，共启用6台 ec2 实例 ( Nginx + Worker x 4 + RabbitMQ + Redis cluster)