定义:高性能架构是指系统能够在单位时间内处理大量请求,并保持快速响应能力的架构设计。
核心目标:
| 年份 | 订单创建峰值(笔/秒) | 较上年增长 |
|---|---|---|
| 2018 | 49.1 万 | - |
| 2019 | 54.4 万 | +10.8% |
| 2020 | 58.3 万 | +7.2% |
注:以上为阿里巴巴官方公布的历届双11订单创建峰值数据(2019 年数据经新华网等媒体报道确认)。
数据洞察:
const tianmaoData = {
year2020: {
peakPerSecond: 583000, // 58.3 万笔/秒(订单创建峰值)
reason: '疫情影响下线上消费占比进一步提升',
growth: '+7.2%'
},
comparison: {
daily: '日常订单创建量可能只有几万笔/秒',
peak: '双11峰值是日常的十倍以上',
challenge: '需要在短时间内处理海量请求'
}
}业务场景:
系统特点:
12306 系统特点:
流量来源:
├── 官方 APP/网站
├── 美团抢票
├── 飞猪抢票
└── 第三方抢票软件
峰值特征:
├── 时间集中(春运期间)
├── 流量突增(秒级暴增)
├── 业务复杂(选座、支付、库存)
└── 数据一致性要求高技术挑战:
典型案例:
场景:明星深夜发布离婚声明
问题:
1. 程序员已下班,无人值守
2. 流量瞬间暴增 10 倍+
3. 扩容速度跟不上流量涌入速度
4. 系统熔断,服务降级
结果:
- 微博崩溃
- 部分用户无法访问
- 服务降级(仅提供基础功能)经验教训:
定义:每秒处理的事务数量
TPS = Transactions Per Second
Transaction(事务)包含:
├── 多个数据库操作
├── 多个接口请求
└── 完整的业务流程
示例:
一次下单事务可能包含:
1. 查询商品库存(SELECT)
2. 扣减库存(UPDATE)
3. 创建订单(INSERT)
4. 扣除余额(UPDATE)
5. 记录日志(INSERT)特点:
定义:每秒查询数量
QPS = Queries Per Second
Query(查询)包含:
├── 数据库查询
├── 缓存查询
├── API 接口调用
└── 单次请求响应
示例:
一次 API 调用可能包含:
1. 查询用户信息(SELECT)→ 1 QPS
2. 查询订单列表(SELECT)→ 1 QPS特点:
定义:每秒处理的请求数量
RPS = Requests Per Second
特点:
- 等同于 QPS
- 侧重于 HTTP 请求层面
- 常用于 Web 服务器性能指标核心问题:TPS、QPS、RPS 哪个值更高?
答案:QPS ≈ RPS > TPS
// 三者关系示例
const metricsComparison = {
// 场景:用户下单
// TPS:一次完整事务
tps: {
value: 1,
description: '下单这个完整业务流程',
includes: [
'查询商品',
'扣减库存',
'创建订单',
'扣除余额',
'发送通知'
]
},
// QPS:多个查询操作
qps: {
value: 5,
description: '5 次数据库查询',
breakdown: [
'SELECT 商品信息',
'SELECT 库存',
'SELECT 用户余额',
'SELECT 收货地址',
'SELECT 优惠券'
]
},
// RPS:多个接口请求
rps: {
value: 5,
description: '5 次 API 调用',
apis: [
'GET /api/product/:id',
'GET /api/inventory/:id',
'GET /api/user/balance',
'GET /api/address',
'POST /api/order/create'
]
}
}
console.log('TPS:', metricsComparison.tps.value) // 1
console.log('QPS:', metricsComparison.qps.value) // 5
console.log('RPS:', metricsComparison.rps.value) // 5| 指标 | 全称 | 含义 | 典型值 | 适用场景 |
|---|---|---|---|---|
| TPS | Transactions Per Second | 每秒事务数 | 较低 | 核心业务性能评估 |
| QPS | Queries Per Second | 每秒查询数 | 较高 | 数据库/API 性能监控 |
| RPS | Requests Per Second | 每秒请求数 | 较高 | Web 服务器性能 |
选择建议:
const metricSelection = {
// 场景1:评估业务系统整体性能
businessSystem: '使用 TPS',
reason: '反映完整业务流程的处理能力',
// 场景2:监控接口性能
apiMonitoring: '使用 QPS/RPS',
reason: '反映接口层面的吞吐量',
// 场景3:数据库性能优化
database: '使用 QPS',
reason: '反映数据库查询压力',
// 场景4:面试场景
interview: '同时了解 TPS、QPS、RPS',
reason: '展示全面的技术理解'
}定义:系统在单位时间内处理的请求数量
表示方式:
计算方式:
// 吞吐量计算示例
class ThroughputCalculator {
// 计算 QPS
calculateQPS(totalRequests, durationSeconds) {
return totalRequests / durationSeconds
}
// 计算 TPS
calculateTPS(totalTransactions, durationSeconds) {
return totalTransactions / durationSeconds
}
// 实时监控
monitorRealtime() {
let requestCount = 0
let startTime = Date.now()
return {
recordRequest: () => {
requestCount++
},
getQPS: () => {
const elapsed = (Date.now() - startTime) / 1000
return Math.floor(requestCount / elapsed)
}
}
}
}
// 使用示例
const calculator = new ThroughputCalculator()
// 计算 1 分钟内处理了 6000 个请求的 QPS
const qps = calculator.calculateQPS(6000, 60)
console.log(`QPS: ${qps}`) // QPS: 100
// 计算 1 小时内完成了 18000 个订单的 TPS
const tps = calculator.calculateTPS(18000, 3600)
console.log(`TPS: ${tps}`) // TPS: 5企业数据保密性:
// 为什么企业不公开性能数据?
const dataConfidentiality = {
reasons: [
'商业机密:用户量、交易量是核心数据',
'安全风险:数据可能被竞争对手利用',
'攻击风险:暴露性能瓶颈,容易被攻击',
'运营策略:数据可能影响市场判断'
],
risk: {
scenario: '攻击者得知系统 QPS 上限',
attack: '在业务低峰期发起 DDoS 攻击',
result: '系统瞬间崩溃'
}
}并发量:系统同时处理的请求数量
计算公式:
并发量 = QPS × 平均响应时间
Concurrent Users = QPS × Average Response Time用户量与并发量关系:
// 用户量与并发量的经验公式
const userToConcurrency = {
// 第一步:总用户数 → 在线用户数
totalToOnline: {
ratio: '10:1',
example: '1000万总用户 → 100万在线用户'
},
// 第二步:在线用户数 → 峰值 QPS
onlineToQPS: {
ratio: '10:1',
example: '100万在线用户 → 10万峰值 QPS'
},
// 第三步:峰值 QPS → 峰值 TPS
qpsToTPS: {
ratio: '约 5:1 到 10:1',
example: '10万峰值 QPS → 1-2万峰值 TPS'
}
}
// 完整计算示例
function calculateSystemCapacity(totalUsers) {
// 在线用户数(约 10%)
const onlineUsers = totalUsers * 0.1
// 峰值 QPS(约在线用户的 10%)
const peakQPS = onlineUsers * 0.1
// 峰值 TPS(约为 QPS 的 1/5 到 1/10)
const peakTPS = peakQPS / 5
return {
totalUsers,
onlineUsers,
peakQPS,
peakTPS
}
}
// 示例:1000万用户的系统
const capacity = calculateSystemCapacity(10000000)
console.log(capacity)
/*
{
totalUsers: 10000000,
onlineUsers: 1000000, // 100万在线
peakQPS: 100000, // 10万 QPS
peakTPS: 20000 // 2万 TPS
}
*/// 电商系统并发量计算
const ecommerceScenario = {
// 业务数据
business: {
totalUsers: 10000000, // 1000万注册用户
dailyActiveUsers: 1000000, // 100万日活
peakOnlineUsers: 500000 // 50万峰值在线
},
// 性能数据
performance: {
averageResponseTime: 0.2, // 平均响应时间 200ms
peakQPS: 50000, // 峰值 QPS 5万
peakTPS: 5000 // 峰值 TPS 5000
},
// 并发量计算
calculation: {
formula: '并发量 = QPS × 平均响应时间',
process: `
1. 峰值 QPS = 50,000
2. 平均响应时间 = 0.2 秒
3. 并发量 = 50,000 × 0.2 = 10,000
结论:系统需要同时处理 10,000 个并发请求
`
}
}// 秒杀系统并发量计算
const seckillScenario = {
// 业务场景
scenario: {
event: 'iPhone 15 限时秒杀',
inventory: 1000, // 库存 1000 台
expectedParticipants: 100000 // 预计 10 万人参与
},
// 流量特征
traffic: {
peakTime: '秒杀开始前后 1 分钟',
peakQPS: 500000, // 峰值 QPS 50万
averageResponseTime: 0.1 // 平均响应 100ms
},
// 并发量计算
calculation: {
concurrentRequests: 500000 * 0.1, // 50,000 并发
challenge: '5万并发请求抢 1000 台手机'
},
// 优化策略
optimization: [
'请求队列 + 限流',
'Redis 预扣库存',
'异步处理订单',
'CDN 静态化'
]
}TPS ≈ QPS 的场景:
示例:
// 场景:用户查询个人信息
// 单一接口请求
GET /api/user/profile
// 单一数据库查询
SELECT * FROM users WHERE id = ?
// 此时:TPS ≈ QPS ≈ RPSTPS < QPS 的场景:
示例:
// 场景:用户下单
// TPS = 1(一次下单事务)
Transaction: 下单
// QPS = 5+(多次查询)
Queries: [
'SELECT 商品信息',
'SELECT 库存',
'SELECT 用户余额',
'SELECT 收货地址',
'SELECT 优惠券'
]
// 此时:TPS << QPS性能监控系统架构:
┌─────────────────────────────────┐
│ 应用服务 │
│ ↓ 发送指标数据 │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 数据收集层 │
│ Prometheus / StatsD │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 数据存储层 │
│ InfluxDB / TimescaleDB │
└─────────────────────────────────┘
↓
┌─────────────────────────────────┐
│ 可视化展示 │
│ Grafana / Kibana │
└─────────────────────────────────┘// 性能监控中间件
class PerformanceMonitor {
constructor() {
this.metrics = {
requests: [],
transactions: []
}
}
// 记录请求(QPS/RPS)
recordRequest(req, res, next) {
const startTime = Date.now()
res.on('finish', () => {
const duration = Date.now() - startTime
this.metrics.requests.push({
path: req.path,
method: req.method,
duration,
timestamp: startTime
})
})
next()
}
// 记录事务(TPS)
recordTransaction(transactionName, callback) {
const startTime = Date.now()
return async (...args) => {
try {
const result = await callback(...args)
const duration = Date.now() - startTime
this.metrics.transactions.push({
name: transactionName,
duration,
timestamp: startTime,
status: 'success'
})
return result
} catch (error) {
const duration = Date.now() - startTime
this.metrics.transactions.push({
name: transactionName,
duration,
timestamp: startTime,
status: 'failed'
})
throw error
}
}
}
// 计算实时 QPS
getQPS(windowMs = 60000) {
const now = Date.now()
const windowStart = now - windowMs
const recentRequests = this.metrics.requests.filter(
req => req.timestamp >= windowStart
)
return recentRequests.length / (windowMs / 1000)
}
// 计算实时 TPS
getTPS(windowMs = 60000) {
const now = Date.now()
const windowStart = now - windowMs
const recentTransactions = this.metrics.transactions.filter(
tx => tx.timestamp >= windowStart
)
return recentTransactions.length / (windowMs / 1000)
}
// 获取性能报告
getPerformanceReport() {
return {
qps: this.getQPS(),
tps: this.getTPS(),
avgResponseTime: this.getAverageResponseTime(),
totalRequests: this.metrics.requests.length,
totalTransactions: this.metrics.transactions.length
}
}
// 计算平均响应时间
getAverageResponseTime() {
if (this.metrics.requests.length === 0) return 0
const totalDuration = this.metrics.requests.reduce(
(sum, req) => sum + req.duration, 0
)
return totalDuration / this.metrics.requests.length
}
}
// 使用示例
const monitor = new PerformanceMonitor()
// 记录请求
app.use(monitor.recordRequest)
// 记录事务
const createOrder = monitor.recordTransaction('createOrder', async (orderData) => {
// 订单创建逻辑
const order = await Order.create(orderData)
return order
})
// 定时输出性能报告
setInterval(() => {
const report = monitor.getPerformanceReport()
console.log('Performance Report:', report)
}, 60000) // 每分钟输出一次# prometheus.yml 配置
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'nodejs-app'
static_configs:
- targets: ['localhost:3000']// Node.js 应用集成 Prometheus
const client = require('prom-client')
// 创建指标
const httpRequestDuration = new client.Histogram({
name: 'http_request_duration_seconds',
help: 'Duration of HTTP requests in seconds',
labelNames: ['method', 'route', 'status_code'],
buckets: [0.1, 0.5, 1, 1.5, 2, 5]
})
const qpsCounter = new client.Counter({
name: 'http_requests', // prom-client 会自动为 Counter 追加 _total 后缀
help: 'Total number of HTTP requests',
labelNames: ['method', 'route']
})
// 中间件
app.use((req, res, next) => {
const start = Date.now()
res.on('finish', () => {
const duration = (Date.now() - start) / 1000
httpRequestDuration
.labels(req.method, req.route, res.statusCode)
.observe(duration)
qpsCounter
.labels(req.method, req.route)
.inc()
})
next()
})
// 暴露指标接口
app.get('/metrics', async (req, res) => {
res.set('Content-Type', client.register.contentType)
res.end(await client.register.metrics())
})特点:
测试流程:
JMeter 性能测试步骤:
1. 创建测试计划
└── 添加线程组(模拟并发用户)
2. 配置采样器
└── HTTP 请求、数据库查询等
3. 添加监听器
└── 查看结果、生成报告
4. 执行测试
└── 收集性能数据
5. 分析结果
└── 生成性能报告简单压力测试:
# 测试 100 个并发用户,总共发送 10000 个请求
ab -n 10000 -c 100 http://localhost:3000/api/users
# 参数说明:
# -n: 总请求数
# -c: 并发数输出示例:
Server Software: Express
Server Hostname: localhost
Server Port: 3000
Document Path: /api/users
Document Length: 1234 bytes
Concurrency Level: 100
Time taken for tests: 10.234 seconds
Complete requests: 10000
Failed requests: 0
Requests per second: 977.12 [#/sec] (mean) ← QPS
Time per request: 102.340 [ms] (mean) ← 平均响应时间高效 HTTP 基准测试工具:
# 测试 12 个线程,400 个连接,持续 30 秒
wrk -t12 -c400 -d30s http://localhost:3000/api/users
# 输出示例:
Running 30s test @ http://localhost:3000/api/users
12 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 102.34ms 45.23ms 1.23s 89.12%
Req/Sec 324.56 89.12 1.23k 76.34%
116789 requests in 30.03s, 145.67MB read
Requests/sec: 3888.45 ← QPS
Transfer/sec: 4.85MB// 性能测试策略矩阵
const testStrategies = {
// 1. 负载测试
loadTest: {
purpose: '测试系统在预期负载下的性能',
steps: [
'逐步增加并发用户',
'观察系统响应',
'找到系统瓶颈'
],
metrics: ['QPS', '响应时间', '资源使用率']
},
// 2. 压力测试
stressTest: {
purpose: '测试系统在极限负载下的表现',
steps: [
'持续增加负载直到系统崩溃',
'找到系统的极限点',
'测试系统的恢复能力'
],
metrics: ['最大 QPS', '崩溃点', '恢复时间']
},
// 3. 并发测试
concurrencyTest: {
purpose: '测试系统同时处理多个请求的能力',
steps: [
'模拟大量并发用户',
'测试数据一致性',
'检测死锁和竞态条件'
],
metrics: ['并发数', '成功率', '错误率']
},
// 4. 耐久性测试
enduranceTest: {
purpose: '测试系统长时间运行的稳定性',
steps: [
'持续运行系统数小时或数天',
'监控内存泄漏',
'观察性能衰减'
],
metrics: ['内存使用', '响应时间变化', '错误率']
}
}# 使用 Artillery 进行性能测试
# artillery.yml
config:
target: 'http://localhost:3000'
phases:
- duration: 60 # 持续 60 秒
arrivalRate: 10 # 每秒 10 个用户
name: "Warm up"
- duration: 120 # 持续 120 秒
arrivalRate: 10
rampTo: 50 # 增加到每秒 50 个用户
name: "Ramp up load"
- duration: 300 # 持续 300 秒
arrivalRate: 50 # 保持每秒 50 个用户
name: "Sustained load"
scenarios:
- name: "User browsing products"
flow:
- get:
url: "/api/products"
- think: 2 # 停顿 2 秒
- get:
url: "/api/products/{{ $randomNumber(1, 100) }}"
- post:
url: "/api/cart/add"
json:
productId: "{{ $randomNumber(1, 100) }}"
quantity: 1
# 运行测试
# artillery run artillery.yml性能优化层次:
应用层优化
├── 代码优化
├── 算法优化
├── 缓存策略
└── 异步处理
数据库层优化
├── 索引优化
├── 查询优化
├── 分库分表
└── 读写分离
架构层优化
├── 负载均衡
├── CDN 加速
├── 微服务拆分
└── 消息队列
基础设施优化
├── 服务器配置
├── 网络优化
├── 容器化部署
└── 自动扩缩容// 多级缓存策略
const cacheStrategy = {
// L1: 本地缓存(内存)
localCache: {
tool: 'node-cache',
ttl: 60,
maxSize: '100MB',
useCase: '热点数据、配置信息'
},
// L2: 分布式缓存
distributedCache: {
tool: 'Redis',
ttl: 3600,
useCase: '会话存储、共享数据'
},
// L3: CDN 缓存
cdn: {
provider: 'CloudFlare / 阿里云 CDN',
ttl: 86400,
useCase: '静态资源、API 响应'
}
}
// 缓存实现示例
class CacheManager {
constructor() {
this.localCache = new Map()
this.redis = new Redis()
}
async get(key) {
// 1. 先查本地缓存
if (this.localCache.has(key)) {
return this.localCache.get(key)
}
// 2. 再查 Redis
const value = await this.redis.get(key)
if (value) {
// 回填本地缓存
this.localCache.set(key, value)
return value
}
// 3. 查数据库
const data = await this.queryDB(key)
if (data) {
// 写入缓存
await this.redis.set(key, data, 'EX', 3600)
this.localCache.set(key, data)
}
return data
}
}// 异步处理提升性能
const asyncOptimization = {
// 场景:订单创建
// 同步处理(慢)
sync: async (orderData) => {
// 1. 创建订单
const order = await Order.create(orderData)
// 2. 扣减库存
await Inventory.decrease(order.productId)
// 3. 扣除余额
await Account.deduct(order.userId, order.amount)
// 4. 发送通知邮件
await Email.send(order.userId, '订单创建成功')
// 5. 发送短信通知
await SMS.send(order.userId, '订单创建成功')
return order
// 总耗时:所有操作耗时之和
},
// 异步处理(快)
async: async (orderData) => {
// 1. 创建订单
const order = await Order.create(orderData)
// 2. 异步处理其他任务
Promise.all([
Inventory.decrease(order.productId),
Account.deduct(order.userId, order.amount)
])
// 3. 发送到消息队列,异步处理
MessageQueue.publish('order.created', {
orderId: order.id,
userId: order.userId
})
return order
// 总耗时:仅核心操作耗时
}
}
// 消息队列消费者
MessageQueue.subscribe('order.created', async (message) => {
const { orderId, userId } = message
// 异步发送通知
await Email.send(userId, '订单创建成功')
await SMS.send(userId, '订单创建成功')
})-- 数据库优化示例
-- 慢查询(全表扫描)
SELECT * FROM orders WHERE user_id = 12345;
-- 添加索引
CREATE INDEX idx_user_id ON orders(user_id);
-- 查询优化(只查询需要的字段)
SELECT id, status, amount FROM orders
WHERE user_id = 12345
ORDER BY created_at DESC
LIMIT 20;
-- 分页优化(避免 OFFSET 过大)
-- 方式1:使用游标
SELECT id, status, amount FROM orders
WHERE user_id = 12345 AND id > 100000
ORDER BY id ASC
LIMIT 20;
-- 方式2:延迟关联
SELECT o.* FROM orders o
INNER JOIN (
SELECT id FROM orders
WHERE user_id = 12345
ORDER BY created_at DESC
LIMIT 10000, 20
) AS tmp ON o.id = tmp.id;读写分离架构:
写入请求(INSERT/UPDATE/DELETE)
↓
┌─────────┐
│ 主数据库 │
└────┬────┘
│ 数据同步
┌────┴────┐
│ │
┌───┴───┐ ┌───┴───┐
│从数据库1│ │从数据库2│
└───────┘ └───────┘
↑ ↑
│ │
读取请求 读取请求实现示例:
// 读写分离实现
class DatabaseManager {
constructor() {
// 主库(写)
this.master = mysql.createConnection({
host: 'master.db.example.com',
user: 'root',
password: 'password',
database: 'myapp'
})
// 从库(读)
this.slaves = [
mysql.createConnection({
host: 'slave1.db.example.com',
user: 'root',
password: 'password',
database: 'myapp'
}),
mysql.createConnection({
host: 'slave2.db.example.com',
user: 'root',
password: 'password',
database: 'myapp'
})
]
this.slaveIndex = 0
}
// 写操作 → 主库
async write(sql, params) {
return new Promise((resolve, reject) => {
this.master.query(sql, params, (error, results) => {
if (error) reject(error)
else resolve(results)
})
})
}
// 读操作 → 从库(轮询)
async read(sql, params) {
const slave = this.slaves[this.slaveIndex]
this.slaveIndex = (this.slaveIndex + 1) % this.slaves.length
return new Promise((resolve, reject) => {
slave.query(sql, params, (error, results) => {
if (error) reject(error)
else resolve(results)
})
})
}
}分库分表策略:
垂直分库:按业务拆分
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 用户库 │ │ 订单库 │ │ 商品库 │
└──────────┘ └──────────┘ └──────────┘
水平分表:按数据量拆分
┌──────────┐ ┌──────────┐ ┌──────────┐
│订单表_0 │ │订单表_1 │ │订单表_2 │
│ user_id │ │ user_id │ │ user_id │
│ %3 = 0 │ │ %3 = 1 │ │ %3 = 2 │
└──────────┘ └──────────┘ └──────────┘分片策略:
// 分片策略实现
class ShardManager {
constructor(shardCount) {
this.shardCount = shardCount
this.shards = this.initShards()
}
// 初始化分片
initShards() {
const shards = []
for (let i = 0; i < this.shardCount; i++) {
shards.push({
connection: mysql.createConnection({
host: `shard${i}.db.example.com`,
database: `order_db_${i}`
})
})
}
return shards
}
// 根据 user_id 决定分片
getShard(userId) {
const shardIndex = userId % this.shardCount
return this.shards[shardIndex]
}
// 插入订单
async insertOrder(userId, orderData) {
const shard = this.getShard(userId)
return new Promise((resolve, reject) => {
const sql = 'INSERT INTO orders SET ?'
shard.connection.query(sql, orderData, (error, results) => {
if (error) reject(error)
else resolve(results)
})
})
}
// 查询订单
async getOrders(userId) {
const shard = this.getShard(userId)
return new Promise((resolve, reject) => {
const sql = 'SELECT * FROM orders WHERE user_id = ?'
shard.connection.query(sql, [userId], (error, results) => {
if (error) reject(error)
else resolve(results)
})
})
}
}| 问题 | 原因 | 解决方案 |
|---|---|---|
| QPS 突然下降 | 数据库慢查询、缓存失效 | 优化 SQL、预热缓存 |
| 响应时间过长 | 代码性能问题、网络延迟 | 代码优化、CDN 加速 |
| 并发量上不去 | 锁竞争、资源瓶颈 | 异步处理、增加资源 |
| 系统频繁崩溃 | 内存泄漏、资源耗尽 | 内存管理、自动扩容 |
| 数据库连接池耗尽 | 连接未释放、并发过高 | 连接池优化、读写分离 |
| 缓存穿透 | 大量无效请求 | 布隆过滤器、空值缓存 |
三大性能指标:
指标关系:
QPS ≈ RPS > TPS
一次事务包含多次查询并发量计算:
并发量 = QPS × 平均响应时间
经验数据:
- 总用户 : 在线用户 = 10 : 1
- 在线用户 : 峰值 QPS = 10 : 1
- 峰值 QPS : 峰值 TPS = 5~10 : 1性能优化策略:
性能测试方法:
答案要点:
答案要点:
并发量 = QPS × 平均响应时间
示例:
QPS = 10,000
平均响应时间 = 0.2 秒
并发量 = 10,000 × 0.2 = 2,000答案要点:
笔记整理完成!
这份笔记详细讲解了高性能架构的核心概念、性能指标、计算方法、监控实战和优化策略,并结合真实案例和代码示例,帮助理解高性能架构设计的核心思想。建议结合实际项目进行性能测试和优化实践。