引言
本文将会描述一个典型的系统架构,然后分析其在理论上是否能够支撑百万并发的请求。
典型系统架构及分析
为了降低复杂性,笔者将系统简化为了下图所示:
该系统架构包含的组件有:
- 网关层:Load Balancer / API Gateway
- 服务层:HTTP Server
- 中间件:Redis、MQ
- 存储层:MySQL / PostgreSQL
忽略业务场景的复杂性,让我们依次分析各个常见的组件。
Load Balancer
负责均衡 & API 网关:
- 负责均衡主要关注的是流量分发这一单一功能。
- API 网关涉及更广泛的功能集,包括但不限于 API 管理、安全、转换、监控等。
- 两者在具体的产品上界限比较模糊。
LB 按类型可分为:硬件负载均衡器、软件负载均衡器、云负载均衡器。
常用的开源软件 LB 包括:Nginx、HAProxy、Kong、Traefik、Envoy 等等。
常见 LB 支持的 RPS(Requests Per Second) 从几万到几十万不等,依赖于硬件和配置。在高性能硬件配置的情况下可以支持百万请求转发。而云服务商提供的 LB 宣称支持百万、千万级别。
参考资料:
HTTP Server
忽略业务处理逻辑,HTTP Server 根据编程语言框架的不同,RPS 从几万到几十万不等,甚至能达到几百万。由于无状态的特性,HTTP Server 也很容易进行横向扩展,因此支持百万并发完全没有问题。
如下图所示:
参考资料:
Redis
一般情况我们认为 Redis 单机 QPS 可以达到 10 万,根据 Redis Cluster 的线性扩展性理论(单机 QPS 为 m,那么 n 台机器的集群的总 QPS 为 m * n,官方文档说集群上限可以有 1000 个节点),Redis 集群可以支撑百万级、甚至千万 QPS。而 AWS 扩展到了单集群 5 亿 QPS。
参考资料:
MQ
对于消息队列,我们把百万并发转换成其每秒接受百万条消息的能力,由于 MQ 往往是追加写入,再加上集群的支持,支撑百万并发也没有什么问题。
参考资料:
MySQL / PostgreSQL
如下是某云服务商提供的 MySQL 5.7 性能测试数据:
从图中可以看到即使是 16C64G 并发度 128 的情况下支持的 QPS 也不到 14 万,TPS 不到 7000。另外再考虑连接数和线程的限制(MySQL 会为每条连接建立一个线程),数据库想要直接支持百万 QPS 不可能,传统关系型数据库是一个明显的瓶颈点,只能做分库、缓存、限流等措施。
参考资料:
网络
网络带宽是一个不可忽视的点。
数据中心的网络带宽常见规格有:10 Gbps、40 Gbps、100 Gbps、400 Gbps 甚至更高。
以 10 Gbps 为例,10 Gbps = 1.25 GB/s,假设每个请求大小是 1 KB,那么每秒 1 百万请求则需要 1 GB/s,可以看出来 10 Gbps 的带宽接近极限。
总结
本文化繁为简,以一个典型的系统架构为例,从理论上分析了各个组件的性能上限,以及对百万并发的支撑情况。对常用组件心中有数,在系统设计时才能有理有据。至于真实业务场景下的系统最大并发数,则只能由系统压测得到结果。