项目背景

https://miaosha.jd.com/
模拟京东秒杀模块，做出秒杀相关的商品列表、商品详情等功能，模拟商品购买时，服务端所需要处理的⼀系列高并发场景，并避免秒杀可能出现的超卖问题。

架构设计

高并发的理论知识

程序 = 算法 + 数据结构
系统 = 服务 + 数据存储

“三高” 高性能 高并发 高可用

QPS = Queries Per Second [⼀秒内可以处理的请求数量]
TPS = Transactions Per Second [⼀秒内可以处理的事务数]
此时的事务 指客户端向服务器发送请求 然后服务器做出响应的过程
https://item.jd.com/10031726008435.html
以此页面为例 ⼀笔url对服务器请求了 180次 对应1次t 180次q
q更具有普适性 所以qps是更准确的衡量标准

rt = response time 响应时间 [传输时间 处理时间 等待时间]
请求从开始到最后收到响应数据所花费的时间

并发数 concurrency 系统同时能处理的请求数量 [负载能力]
公式: QPS = 并发数/平均响应时间

产品的指标：
PV = page view 每个页面的浏览次数
UV = unique visitor 每天访问的用户数

服务的链路

秒杀难，难于上青天，难在哪？

i） 比如秒杀商品为荣耀手机，指定限购100件，每人限购1件
同⼀时间的请求量 是上万或更多 系统和数据库都要承担很大的压力

ii） 服务的处理链路复杂

解决高并发的思路

A 浏览器
限制一个用户在一定时间内的请求量 （ip层面的限制要慎重）
限制同一用户使用ip的数量不能过多 （可能用公网，比如校园网，大家ip地址是一样的）
限制已秒杀成功的用户 不能继续请求（从用户ID方面进行限制）
在秒杀的时刻 才开放真正的秒杀链接 避免机器人和黄牛

B 站点
针对高频请求，将响应做缓存

C 服务
增加请求队列（排队，先来先处理）

D 数据
读写问题
超卖问题 （分布式锁）

总结：
a）尽量将请求拦截在系统上游
b) 尽量读多写少，且使用缓存