高并发架构设计要点

高并发并不只是“能扛很多请求”，而是系统在海量请求下仍然具备高性能、高可用性和可扩展性。

一、核心主线

本节主要回答三个问题：

1
2
3
4
5

什么样的系统才算高并发系统？
        ↓
如何衡量高并发系统设计得好不好？
        ↓
高并发场景应该如何分类？

二、形成高并发系统的三个必要条件

1. 高性能

高性能表示系统具备较强的并行处理能力。

它的价值体现在两个方面：

• 节约硬件资源：同样硬件条件下，性能越高，能处理的请求越多；
• 保障用户体验：响应时间越短，用户感知越流畅。

如果系统响应时间过长，即使最终没有报错，用户体验也会明显下降。

2. 高可用性

高可用性表示系统可以长期稳定、正常地对外提供服务。

一个高并发系统不能只是“高峰时跑得快”，还要做到：

• 不频繁故障；
• 不经常宕机；
• 不容易崩溃；
• 出现问题后能快速恢复。

高并发场景下，请求量大、影响用户多，因此系统故障的业务影响会被放大。

3. 可扩展性

可扩展性表示系统可以通过水平扩容来应对请求量增长。

当请求量持续增长或突发激增时，系统应该能通过增加机器、节点或实例来提升处理能力，而不是每次都要重新做架构改造。

1
2
3
4
5

请求量增加
   ↓
增加服务节点
   ↓
系统吞吐能力随之提升

可扩展性是高并发系统应对未来增长的关键。

三、高并发系统的衡量指标

1. 高性能指标

1.1 平均响应时间的问题

平均响应时间是一个容易想到的指标：

1

平均响应时间 = 所有请求响应时间之和 / 请求数量

但平均值容易被极端值掩盖问题。

例如：

1
2

9900 个请求响应时间：1 ms
100 个请求响应时间：100 ms

平均响应时间只有约 1.99 ms，看起来很好，但实际上仍有一部分用户经历了明显更慢的响应。

因此，平均响应时间不足以完整反映系统性能。

1.2 PCTn 分位值

推荐使用 PCTn 衡量响应时间。

PCTn 表示：

将请求响应时间从小到大排序后，第 n 分位对应的响应时间。

例如：

分位值越高，越能反映长尾请求的性能问题。

1.3 推荐性能标准

给出的经验判断是：

1
2

平均响应时间 ≈ 200 ms
且 PCT99 ≈ 1 s

这样的高并发系统基本可以满足高性能要求。

原因是：

• 响应时间在 200 ms 以内，用户通常不容易感受到延迟；
• 响应时间超过 1 s，用户会明显感受到卡顿。

2. 高可用性指标

可用性表示系统正常运行时间占总运行时间的比例：

1

可用性 = 系统正常运行时间 / 系统总运行时间

通常使用“几个 9”描述系统可用性。

高可用系统通常至少要求：

• 3 个 9；
• 或 4 个 9。

很多公司会使用 99.95% 作为可用性监控阈值。

当系统可用性低于阈值时，应及时告警，并推动：

• 故障恢复；
• 容量扩容；
• 故障原因分析；
• 系统架构改造。

3. 可扩展性指标

可扩展性衡量的是：增加节点后，系统吞吐能力能提升多少。

公式：

1

可扩展性 = 吞吐量提升比例 / 集群节点增加比例

理想情况是：

1
2
3

节点增加 N 倍
   ↓
吞吐量也增加 N 倍

但现实系统中，扩容通常会受到共享资源、网络、存储、锁竞争、调度开销等因素影响，很难做到 100% 线性增长。

经验标准是：

1

70%～80% 的可扩展性

基本可以满足可扩展性要求。

四、高并发场景分类

计算机系统中的业务功能最终都会落到数据操作上，而数据操作主要分为两类：

1
2

读
写

因此，高并发场景也可以分为：

1. 高并发读

读请求远多于写请求。

典型场景：

• 刷帖子；
• 浏览商品；
• 浏览 Feed；
• 查看文章；
• 搜索内容。

这类场景的重点是提升数据读取能力。

后续常见方案包括：

• 数据库读写分离；
• 本地缓存；
• 分布式缓存；
• CQRS。

2. 高并发写

写请求压力较大。

典型场景：

• 发帖；
• 点赞；
• 评论；
• 下单；
• 计数更新；
• IM 消息写入。

这类场景的重点是提升写入吞吐能力，并控制写入热点。

后续常见方案包括：

• 数据分片；
• 分库分表；
• 异步写；
• 写聚合。

3. 读多写多

部分业务同时存在大量读请求和大量写请求。

这类系统需要同时解决：

• 读扩展；
• 写扩展；
• 数据一致性；
• 缓存更新；
• 存储扩容；
• 热点数据处理。

五、核心架构思想

1. 高并发不是单纯的高请求量，而是高请求量下仍能保持高性能、高可用和可扩展。
2. 高性能关注响应时间，尤其要关注 PCT99、PCT999 等长尾延迟。
3. 平均响应时间容易掩盖极端慢请求，不适合作为唯一性能指标。
4. 高可用关注系统长期稳定运行的概率，通常用几个 9 衡量。
5. 高并发系统至少应追求 3 个 9 或 4 个 9 的可用性。
6. 可扩展性关注水平扩容后吞吐量是否能同步提升。
7. 理想扩展是线性扩展，现实中达到 70%～80% 已基本可接受。
8. 高并发问题应先按读、写场景分类，再选择对应架构方案。
9. 读多写少、写多读少、读多写多对应的架构重点不同。
10. 高并发架构设计的本质是围绕性能、可用性、扩展性做系统性权衡。

六、一句话总结

高并发系统不仅要能处理海量请求，还必须同时具备高性能、高可用性和可扩展性；性能应关注 PCT 分位响应时间，可用性用几个 9 衡量，可扩展性用吞吐提升比例与节点增加比例衡量，而具体高并发方案应先按高并发读和高并发写场景进行分类。