1 背景
上一章中，我们已经把秒杀的架构设计已经讲完了，顺便做了一些技术方面的实战分析。要想做好一个秒杀系统，不是说把项目搭建起来运行就可以了，秒杀活动说白了也就几秒甚至都不到1秒就结束了，我们需要在活动开始前做大量的支撑工作才可以，同时还需要做大量的售后工作，今天我们就秒杀系统的浏览和数据工作再梳理一下。
2 秒杀流量控制方案
秒杀流量的模型，我们可以理解为一个倒立的金字塔模型，入口的流量很大，每经过一层都会过滤掉一部分，真正执行的可能都不足万分之一的流量。这就要求我们在前期做好流量的控制。
2.1 预约系统
秒杀商品要么价格低，性价比高，甚至像茅台这种有收藏和盈利空间，所以就会有很多灰色的流量，甚至是一些自动化的流量，如果只是通过网关限流来控制，可能达不到风控的目的。所以需要提前进行预约，这也是很多秒杀活动的新玩法，这就需要我们搞一个预约的接口，在网关层风控里面过滤掉这些自动化的流量。如果活动实在过于火爆的话，预约系统还可以控制流量的上限，预约活动一般要提前结束，给系统留出时间去把预约用户的相关信息热处理到redis中。
2.2 流量削峰
上节课，秒杀系统中我们已经提到过这个概念。我们可以通过验证码或者答题的环节来消减流量的峰值。这个是通过用户的反应时差和答题速度来实现削峰操作。
还有一种就是消息队列的方式，当队列满了之后，对之后的流量进行丢弃啊之类的操作
根据路由哈希操作，可以IP等进行哈希操作，类似布隆过滤器的原理，只允许特定的用户通过，这个也是常见的手段。
总之。这个地方的玩法比较流氓，规则你自己制定，你想怎么搞都行。
2.3 限流
限流这个需要从网关的技术层面进行处理：
nginx 本身也提供了非常强大的限流功能，比如有两个专门的限流模块HttpLimitzone 和 HttpLimitReqest，HttpLimitzone 用来限制一个客户端的并发连接数，HttpLimitReqest 通过漏桶算法来限制用户的连接频率。
网关GateWay + redis 组成的 令牌桶算法，一定时间内可以允许多少流量通过
网关GateWay + sentinel 中间件组合进行限流，这个我们后面在 熔断降级的时候会仔细去讲。
除了在技术层面，业务层面也可限制下，比如没有库存了，我们在nginx+redis 就可以判断出，用lua脚本直接返回 秒杀结束，这样这些无效的流量就不用走到下一层了。
还可以通过黑白明白对流量进行限制
3 热点数据方案
我们的数据一般都存在数据库中，如果请求量过大，会导致数据库崩溃，所以热点的数据我们一般都会使用缓存。如果遇到流量突增的情况，可以通过水平扩展来进行扩容。
数据库的读写分离
redis的分片读取
4 库存处理
当我们下单时会对缓存中的库存进行预占的扣减操作，当缓存的库存不够时，就是秒杀活动结束的时候。库存的扣减非常重要，因为在秒杀环节中不能出现超卖的问题。
redis 缓存中的预占库存的操作 使用 decr 函数操作
数据库中利用行锁进行控制，每次操作加上 for update,事务结束时，释放锁
在where 条件中增加 库存 > 0 的条件限制
使用乐观锁机制，通过version 字段进行控制
利用数据库字段的特性，字段值大于0，小于0时报错的特性
5 容灾
容灾，一般是指搭建多套(两套或以上)相同的系统，当其中一个系统出现故障时，其他系统能快速进行接管，从而持续提供 7*24 不间断业务。
同城双活
异地多活
6 总结
在秒杀系统中，控制好流量和热点数据，保证好系统的稳定性，你就成功了一半。剩下的一半就交给业务系统去验证吧。
如果大家喜欢，别忘了一键三连啊，记得关注哦
免费领取108个优质赚钱项目，加微信：tuk818 备注：项目！
