在分布式系统、互联网架构设计中,高性能(High Performance)、高可用(High Availability)、高并发(High Concurrency) 是三大核心设计目标,被统称为 “三高”。三者并非孤立存在:高并发是业务场景(系统面临的请求量特征),高性能是核心结果(系统处理请求的效率),高可用是底线要求(系统在异常下持续服务的能力),最终共同支撑系统在海量请求、复杂场景下稳定、高效、持续地提供服务。
本文将从核心定义、关键指标、核心优化策略、典型实践四个维度拆解三者,并分析其协同关系与平衡原则,同时结合实际业务场景给出落地思路,内容兼顾理论深度与工程实践。
先搞懂:三高核心差异与关联(结构化梳理)
很多人容易混淆高并发与高性能、高可用的边界,先通过表格明确三者的核心定位、关注重点和关键逻辑,建立整体认知:
表格
| 维度 | 高并发(High Concurrency) | 高性能(High Performance) | 高可用(High Availability) |
|---|---|---|---|
| 核心目标 | 支撑大量请求同时访问系统 | 让系统处理请求更快、更高效 | 让系统在各种异常下持续提供服务 |
| 关注重点 | 请求的 “并发量”,解决 “请求挤兑” 问题 | 请求的 “处理效率”,解决 “响应慢、吞吐低” 问题 | 服务的 “连续性”,解决 “故障导致服务不可用” 问题 |
| 核心指标 | QPS/TPS、并发用户数、请求排队长度 | 响应时间(P50/P95/P99)、吞吐量、资源利用率 | 可用性等级(N 个 9)、MTTR、MTBF、故障覆盖率 |
| 核心逻辑 | 「分流、削峰、扩容」,分散请求压力 | 「提速、减负、优化」,提升单请求处理效率 | 「冗余、容错、自愈」,消除单点故障 |
| 与其他关联 | 高并发是高性能的典型应用场景,高并发下的性能衰减是核心问题 | 高性能是高并发的基础保障,高性能系统能支撑更高的并发量 | 高可用是高并发、高性能的底线,再高的并发和性能,服务不可用则无意义 |
关键共识:三高优化没有 “银弹”,需结合业务场景(如电商秒杀、政务系统、金融交易)、资源成本(服务器、中间件、人力)做取舍,比如部分场景可通过 “牺牲少量性能” 换取更高的可用性,或通过 “限流” 控制并发来保障核心服务的性能和可用。
一、高并发:支撑海量请求同时访问的能力
核心定义
高并发指系统能够同时处理大量用户请求(如电商秒杀的瞬间十万 / 百万级请求、社交平台的热点事件刷屏)的能力,核心解决请求集中式挤兑导致的系统拥堵、超时甚至崩溃问题。
高并发的本质是 **“请求压力的分散与管控”**,而非单纯追求 “请求量越大越好”,核心是让系统在并发峰值下仍能有序处理请求。
关键量化指标
- QPS/TPS:最核心指标,QPS(Queries Per Second)是每秒查询数(读请求为主),TPS(Transactions Per Second)是每秒事务数(读写结合的完整业务流程,如下单、支付);
- 并发用户数:系统同时承载的在线用户数(注意:并发用户数≠QPS,如 1 个用户 1 秒发起 5 次请求,1000 并发用户可能对应 5000 QPS);
- 请求排队长度:系统等待处理的请求数,排队过长会导致请求超时,是并发压力的直接体现;
- 峰值并发:系统在业务高峰(如秒杀、双十一)的最大并发量,是架构设计的核心参考值。
核心优化策略(分层设计,从接入到存储)
高并发优化遵循 **“分流→削峰→扩容→解耦”** 原则,从请求进入系统的第一层开始,层层分散压力,避免压力集中在某一节点。
1. 接入层:请求入口分流,拦截无效请求
- 负载均衡:通过 Nginx、LVS、云负载均衡(SLB)将请求分发到多个应用节点,避免单节点扛所有压力;
- 限流:核心手段,对超出系统处理能力的请求进行 “拦截”,常用策略:计数器、漏桶、令牌桶(如 Sentinel、Hystrix、Redis+Lua 实现),支持按 IP、接口、用户维度限流;
- CDN 加速:将静态资源(图片、JS、CSS)部署到 CDN 节点,让用户从就近节点获取资源,减少源站请求量;
- 黑白名单:

深度解析&spm=1001.2101.3001.5002&articleId=157840322&d=1&t=3&u=ec2f6b616b4c44a0b8a1f2ede92c8b6a)
2148

被折叠的 条评论
为什么被折叠?



