引言：高并发的世界观 · 高并发系统设计

1.1 DEFINITION

高并发的定义：不是数字，是"压力感"

想象一家奶茶店：平时一分钟来 2 个客人，店员优哉游哉。突然网红探店视频爆了，一分钟涌进来 200 个人——店还是那个店，但一切都变了：排队排到马路上（请求堆积）、店员手忙脚乱做错单（数据出错）、收银机卡死（系统崩溃）。

高并发（High Concurrency）指的就是：系统在同一时间段内需要处理大量请求，多到单台机器、朴素写法已经扛不住，必须专门设计架构来应对的状态。

所以"高"没有绝对数字门槛——对一个用 SQLite 的博客，100 QPS 就是高并发；对淘宝双11，百万 QPS 才算进入状态。判断标准是"压力是否逼你改架构"，而不是某个具体数值。

💡

一句话记住：高并发不是炫技名词，而是一种被流量逼出来的工程约束。后面 7 个场景，本质都是同一个问题在不同业态下的变形：请求太多，资源有限，如何优雅地"接住"。

1.2 METRICS

这五个词是全站的"通用货币"，后面每一页都会反复出现。用奶茶店类比一次讲透。

QPS每秒查询数（吞吐量）

系统每秒能处理多少个请求，衡量"店的接客速度"。写请求场景也常说 TPS（每秒事务数）。

🧋 奶茶店每秒卖出 3 杯 → QPS = 3。淘宝双11峰值订单创建约 58.3 万笔/秒（2020年公开数据）。

RT响应时间（Response Time）

一个请求从发出到收到结果的耗时，衡量"顾客从点单到拿到奶茶等了多久"。通常以毫秒计。

🧋 用户体感参考：<100ms 无感，100~300ms 可接受，>1s 开始烦躁，>3s 大量流失。

P9999分位延迟（尾延迟）

把所有请求的耗时从快到慢排序，第 99% 位置的那个值。平均值会骗人，P99 不会——它代表"最倒霉的那 1% 顾客等了多久"。

🧋 100 个顾客，99 个 1 分钟拿到，1 个等了 30 分钟：平均 1.3 分钟很好看，但 P99 = 30 分钟，暴露了真实的糟糕体验。

并发数同时在处理的请求数

某一瞬间系统里"正在被服务"的请求数量。经典关系：并发数 ≈ QPS × 平均RT（利特尔法则）。RT 越长，同样 QPS 下积压的并发越多。

🧋 每秒进店 10 人（QPS=10），每人平均耗时 3 秒（RT=3s）→ 店里同时约有 30 人在被服务。

SLA可用性服务等级协议（几个9）

系统承诺的"营业可靠度"。99.9% 听起来很高，但换算成停机时间就直观了：

可用性	俗称	全年最多停机	直观感受
99%	2个9	≈ 3.65 天	每月宕机大半天，用户会跑光
99.9%	3个9	≈ 8.76 小时	一般内部系统的及格线
99.99%	4个9	≈ 52.6 分钟	主流互联网服务的标配目标
99.999%	5个9	≈ 5.26 分钟	金融/电信级，代价极其昂贵

高并发优化的很多功夫，其实都花在"砍掉长尾"上——因为在微服务里一个请求要串多个服务，尾延迟会被链式放大。

1.3 TRADE-OFF

性能、一致性、可用性——三者不可兼得的博弈，是理解一切架构取舍的钥匙。

点赞数晚几秒才准没人在意，但页面必须秒开、服务不能挂。于是用缓存 + 异步落库，接受"最终一致"。这是互联网最常见的选择。

钱错一分都不行，服务也要稳，那就上强事务、加锁、同步复制——代价是单笔更慢、吞吐更低，用更多机器和更贵的方案来堆。

库存必须精确、下单必须快，那就干脆"拒绝"大部分人：限流、排队、验证码劝退——牺牲的是"每个人都能被服务"的可用体验。

接下来 7 个场景，每一个都是这个三角形的不同"站位"：秒杀偏一致、Feed 流偏性能、支付死守一致、弹幕彻底拥抱丢弃。看懂站位，就看懂了选型。