高性能架构 学习笔记
一、高性能架构概述
1.1 什么是高性能架构？
定义：高性能架构是指系统能够在单位时间内处理大量请求，并保持快速响应能力的架构设计。
核心目标：
- 高吞吐量：处理更多请求
- 低延迟：快速响应用户
- 高并发：支持大量用户同时访问
1.2 真实案例数据
1.2.1 天猫双十一数据
| 年份 | 数据库处理峰值（TPS） | 增长率 |
|---|---|---|
| 2018 | 约 5000 万次/秒 | - |
| 2019 | 8700 万次/秒 | 基准 |
| 2020 | 1.4 亿次/秒 | +60% |
数据洞察：
javascript
const tianmaoData = {
year2020: {
tps: 140000000, // 1.4 亿次/秒
reason: '疫情影响，全民居家购物',
growth: '60%'
},
comparison: {
daily: '日常 TPS 可能只有几十万',
peak: '双十一峰值是日常的几百倍',
challenge: '需要在短时间内处理海量请求'
}
}1.2.2 12306 抢票系统
业务场景：
- 春运期间抢票高峰
- 第三方平台流量（美团、飞猪）
- 抢票软件刷票请求
系统特点：
code
12306 系统特点：
流量来源：
├── 官方 APP/网站
├── 美团抢票
├── 飞猪抢票
└── 第三方抢票软件
峰值特征：
├── 时间集中（春运期间）
├── 流量突增（秒级暴增）
├── 业务复杂（选座、支付、库存）
└── 数据一致性要求高技术挑战：
- 库存扣减的原子性
- 高并发下的数据一致性
- 防止超卖
- 快速响应
1.2.3 微博热点事件
典型案例：
code
场景：明星深夜发布离婚声明
问题：
1. 程序员已下班，无人值守
2. 流量瞬间暴增 10 倍+
3. 扩容速度跟不上流量涌入速度
4. 系统熔断，服务降级
结果：
- 微博崩溃
- 部分用户无法访问
- 服务降级（仅提供基础功能）经验教训：
- 需要实时监控系统
- 自动化扩容机制
- 预案和降级策略
二、核心性能指标
2.1 三大核心指标
2.1.1 TPS（Transactions Per Second）
定义：每秒处理的事务数量
code
TPS = Transactions Per Second
Transaction（事务）包含：
├── 多个数据库操作
├── 多个接口请求
└── 完整的业务流程
示例：
一次下单事务可能包含：
1. 查询商品库存（SELECT）
2. 扣减库存（UPDATE）
3. 创建订单（INSERT）
4. 扣除余额（UPDATE）
5. 记录日志（INSERT）特点：
- 代表完整的业务操作
- 指标值相对较低
- 更能反映系统真实性能
2.1.2 QPS（Queries Per Second）
定义：每秒查询数量
code
QPS = Queries Per Second
Query（查询）包含：
├── 数据库查询
├── 缓存查询
├── API 接口调用
└── 单次请求响应
示例：
一次 API 调用可能包含：
1. 查询用户信息（SELECT）→ 1 QPS
2. 查询订单列表（SELECT）→ 1 QPS特点：
- 代表接口层面的性能
- 指标值相对较高
- 常用于接口性能监控
2.1.3 RPS（Requests Per Second）
定义：每秒处理的请求数量
code
RPS = Requests Per Second
特点：
- 等同于 QPS
- 侧重于 HTTP 请求层面
- 常用于 Web 服务器性能指标