Java岗大厂面试百日冲刺【Day49】— 十个面试九个秒杀1 （日积月累，每日三题）

  大家好，我是陈哈哈，北漂五年。相信大家和我一样，都有一个大厂梦，作为一名资深Java选手，深知面试重要性，接下来我准备用100天时间，基于Java岗面试中的高频面试题，以每日3题的形式，带你过一遍热门面试题及恰如其分的解答。

  一路走来，随着问题加深，发现不会的也愈来愈多。但底气着实足了不少，相信不少朋友和我一样，日积月累才是最有效的学习方式！想起高三时一个同学的座右铭：只有沉下去，才能浮上来。共勉（juan）。

  好久不见，你狗哥又双回来了~

作者：爪哇小白2021

---

---

  本栏目Java开发岗高频面试题主要出自以下各技术栈：Java基础知识、集合容器、并发编程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL数据库、Redis缓存、RabbitMQ消息队列、Linux操作技巧等。

面试题1：你是怎么理解秒杀系统的？

  相信对你来说，秒杀这个词肯定不陌生；从双十一购物到春节抢红包，再到 12306 抢火车票，“秒杀”的场景处处可见。简单来说，秒杀就是在同一个时刻有大量的请求争抢购买同一个商品并完成交易的过程，用技术角度说就是大量的并发读和并发写。

  如果你看过秒杀系统的流量监控图的话，你会发现秒杀就是那种瞬间流量很高，但是平时又没有流量的场景。就在秒杀开始那一秒是一个很高的峰，这是因为秒杀请求在时间上高度集中于某一特定的时间点。这就会导致一个特别高的流量峰值，它对资源的消耗是瞬时的。（这里借张敖丙老哥的流量峰值图）

  对秒杀这个场景来说，最终能够抢到商品的人数是固定的，比如秒杀活动有100台iphone13手机，那么100人和10000人发起请求的结果其实都是一样的，只有100个是有效的请求而已，并发度越高，无效请求也越多。

  但是从业务上来说，秒杀活动是希望更多的人来参与的，也就是开始之前希望有更多的人来刷页面，但真正开始下单时，秒杀请求并不是越多越好。

  因此我们需要设计一些规则，让并发的请求得到更多的缓冲，同时我们也要过滤掉一大批无效请求。

---

一、秒杀业务的典型特点：

1. 瞬时流量大 ，参与用户多；
2. 可秒杀商品数量少 ；
3. 并发读远大于并发写；
4. 秒杀状态的实时性更新要求高；

一次秒杀的流程可以分为三个阶段：

1. 秒杀未开始

  活动开始前，用户进入活动页，这个阶段有两种请求，一种是加载活动页信息，一个是查询活动状态得到未开始的结果， 一个用户进入页面两个请求各发起一次，这两种请求占比各半。

2. 秒杀进行中

  这个阶段持续时间非常短，看到抢购按钮（开始）的用户大量发起秒杀请求，瞬时秒杀请求占比暴增，抗住这些秒杀请求就是秒杀系统是否能抗住高并发的关键。

3. 秒杀结束

  当商品被抢购完，进入结束状态，请求情况回到活动开始前。

  秒杀系统主要围绕活动开始时间和剩余库存两个关键因素进行；坦白说其实贯穿整个活动的关键请求只有三种：加载活动页请求、读取活动状态请求、秒杀下单请求。

---

  秒杀的整体架构可以概括为稳、准、快三个字，对应的分别是高可用、数据一致性、高性能。

• 稳（高可用）

  整个秒杀系统架构需要满足高可用，我们通常衡量一个Web系统的吞吐率的指标是QPS（Query Per Second，每秒处理请求数）。QPS在预计水位线以下时要保证稳定，当QPS超出预期时也同样不能让系统挂掉，要保证秒杀活动顺利完成，秒杀商品顺利地卖出去，这个是最基本的要求。

• 准（数据一致性）

  准就是保证数据的一致性，比如秒杀100台 iPhone13，那就只能成交100台，多一台少一台都不行。一旦库存出问题，平台就要承担损失，程序员就要被祭天。程序员：？？？

• 快（高性能）

  高性能，请求速度要快。这就要求系统的性能要足够高，否则你怎么支撑这么大的流量呢？不光是服务端要做极致的性能优化，而且在整个请求链路上都要做协同的优化。包括浏览器端、CDN、前端界面、服务端负载、服务端、缓存端、RPC、请求队列、DB端等，每个地方都快一点，整个系统就完美了。

二、秒杀架构的几个原则

1、程序尽可能做得少

  一方面是指在功能特性上有所为，有所不为；另一方面是指一次处理的信息量要少。接口负责的功能越少，读取信息量越少，速度越快。

2、尽量将请求拦截在系统上游

  传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时。秒杀中虽然流量很大，但实际下单的有效流量却很小。你想100台iphone13手机，10万个人抢，其中有效请求也就那100条，请求有效率为0.1%。

3、读多写少的场景尽量用缓存

  秒杀是典型的读多写少的应用场景，100台iphone13手机，10万个人抢，最多100个人下单成功，其他人其实都是到查库存这一步就没了，写比例占0.1%，读比例占99.9%，缓存的典型使用场景。

---

课间休息，又来秀一下来自咱们群里同学的搬砖工地，坐标：南京。

作者：griz