为什么秒杀系统的设计是一个难点呢？ 是因为它的业务复杂么？ 当然不是！
秒杀系统的业务逻辑非常简单，一般就是下订单减库存，难点在于我们如何保障秒杀能够顺利进行。
高并发&高性能
热点数据处理
何为热点数据？ 热点数据指的就是某一时间段内被大量访问的数据，比如爆款商品的数据、新闻热点。
为什么要关注热点数据？ 热点数据可能仅仅占据系统所有数据的 0.1% ，但是其访问量可能是比其他所有数据之和还要多。不重点处理热点数据，势必会给系统资源消耗带来严峻的挑战。
热点数据的分类？ 根据热点数据的特点，我们通常将其分为两类：
● 静态热点数据 ：可以提前预测到的热点数据比如要秒杀的商品。
● 动态热点数据 ： 不能够提前预测到的热点数据，需要通过一些手段动态检测系统运行情况产生。
另外，处理热点数据的问题的关键就在于 我们如何找到这些热点数据（或者说热 key），然后将它们存在 jvm 内存里。 对于并发量非常一般的系统直接将热点数据存放进缓存比如 Redis 中就可以了，不过像淘宝、京东这种级别的并发量，如果把某些热点数据放在 Redis 中，直接可能就将整个 Redis 集群给干掉了。
如何检测热点数据？
我了解到的是市面上也有一些类似的中间件，比如京东零售的 hotkey 就是一款专门用于检测热点数据的中间件，它可以毫秒级探测热点数据，毫秒级推送至服务器集群内存。
另外，我们平时使用 Redis 做缓存比较多，关于如何快速定位 Redis 热点数据，可以看下如何快速定位 Redis 热 key这篇文章。
流量削峰
消息队列
秒杀开始之后的流量不是很大，我处理不了嘛！那我就先把这些请求放到消息队列中去。然后，咱后端服务再慢慢根据自己的能力去消费这些消息，这样就避免直接把后端服务打垮掉。
回答问题/验证码
我们可以在用户发起秒杀请求之前让其进行答题或者输入验证码。
这种方式一方面可以避免用户请求过于集中，另一方面可以有效解决用户使用脚本作弊。
回答问题/验证码这一步建议除了对答案的正确性做校验，还需要对用户的提交时间做校验，比如提交时间过短（<1s）的话，大概就是使用脚本来处理的。
高可用
集群化
如果我们想要保证系统中某一个组件的高可用，往往需要搭建集群来避免单点风险，比如说 Nginx 集群、Kafka 集群、Redis 集群。
我们拿 Redis 来举例说明。如果我们需要保证 Redis 高可用的话，该怎么做呢？
你直接通过 Redis replication（异步复制） 搞个一主(master)多从(slave)来提高可用性和读吞吐量，slave 的多少取决于你的读吞吐量。
这样的方式有一个问题：一旦 master 宕机，slave 晋升成 master，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
不过，这个问题我们可以通过 Sentinel（哨兵） 来解决。Redis Sentinel 是 Redis 官方推荐的高可用性(HA)解决方案。
Sentinel 是 Redis 的一种运行模式 ，它主要的作用就是对 Redis 运行节点进行监控。当 master 节点出现故障的时候， Sentinel 会帮助我们实现故障转移，确保整个 Redis 系统的可用性。整个过程完全自动，不需要人工介入!
限流
限流是从用户访问压力的角度来考虑如何应对系统故障。限流为了对服务端的接口接受请求的频率进行限制，防止服务挂掉。
? 举个例子：我们的秒杀接口一秒只能处理 10w 个请求，结果秒杀活动刚开始一下子来了 15w 个请求。这肯定不行啊！我们只能通过限流把 5w 个请求给拦截住，不然系统直接就给整挂掉了！
限流的话可以直接用 Redis 来做（建议基于 Lua 脚本），也可以使用现成的流量控制组件比如 Sentinel 、Hystrix 、Resilience4J 。
Hystrix 是 Netflix 开源的熔断降级组件。
Sentinel 是阿里巴巴体提供的面向分布式服务架构的流量控制组件，经历了淘宝近10年双11（11.11）购物节的所有核心场景（比如秒杀活动）的考验。
Sentinel 主要以流量为切入点，提供 流量控制、熔断降级、系统自适应保护等功能来保护系统的稳定性和可用性。
降级
降级是从系统功能优先级的角度考虑如何应对系统故障。
服务降级指的是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级的核心思想就是丢车保帅，优先保证核心业务。例
? 举个例子：当请求量达到一个阈值的时候，我们对系统中一些非核心的功能直接关闭或者让它们功能降低。这样的话，系统就有更多的资源留给秒杀功能了！
熔断
熔断和降级是两个比较容易混淆的概念，两者的含义并不相同。降级的目的在于应对系统自身的故障，而熔断的目的在于应对当前系统依赖的外部系统或者第三方系统的故障。
熔断可以防止因为秒杀交易影响到其他正常服务的提供
? 举个例子： 秒杀功能位于服务 A 上，服务 A 上同时还有其他的一些功能比如商品管理。如果服务 A 上的商品管理接口响应非常慢的话，其他服务直接不再请求服务 A 上的商品管理这个接口，从而有效避免其他服务被拖慢甚至拖死。
一致性
减库存方案
常见的减库存方案有：
● 下单即减库存 ：只要用户下单了，即使不付款，我们就扣库存。
● 付款再减库存 ：当用户付款了之后，我们在减库存。不过， 这种情况可能会造成用户下订单成功，但是付款失败。
一般情况下都是 下单减扣库存 ，像现在的购物网站比如京东都是这样来做的。
不过，我们还会对业务逻辑做进一步优化，比如说对超过一定时间不付款的订单特殊处理，释放库存。
对应到代码层面，我们应该如何保证不会超卖呢？
我们上面也说，我们一般会提前将秒杀商品的信息放到缓存中去。我们可以通过 Redis 对库存进行原子操作。伪代码如下：
性能测试
上线之前压力测试是必不可少的。推荐 4 个比较常用的性能测试工具：
1 Jmeter ：Apache JMeter 是 JAVA 开发的性能测试工具。
2 LoadRunner：一款商业的性能测试工具。
3 Galtling ：一款基于 Scala 开发的高性能服务器性能测试工具。
4 ab ：全称为 Apache Bench 。Apache 旗下的一款测试工具，非常实用。
没记错的话，除了 LoadRunner 其他几款性能测试工具都是开源免费的。
总结
我简单画了一张图来总结一下上面涉及到的一些技术。
另外，上面涉及到知识点还蛮多的，如果面试官单独挑出一个来深挖还是能够问出很多问题的。
比如面试官想在消息队里上进行深挖，可能会问：
● 常见消息队列的对比
● 如何保证消息的消费顺序？
● 如何保证消息不丢失？
● 如何保证消息不重复消费？
● 如何设计一个消息队列？
● ……
再比如面试官想在 Redis 上深挖的话，可能会问：
● Redis 常用的数据结构了解么？
● Redis 如何保证数据不丢失？
● Redis 内存占用过大导致响应速度变慢怎么解决？
● 缓存穿透、缓存雪崩了解么？怎么解决？
● ……
因此，要想要真正搞懂秒杀系统的设计，你还需要将其涉及到的一些技术给研究透！
