Skip to main content

服务高并发

· 5 min read

后端服务监听端口，客户端发起请求，首先建立 tcp 连接，使用 http 协议。

客户端连接池，连接复用情况。

后端服务接收到请求，立马开启一个 goroutine 处理，这个处理的最大数？

百万请求后端服务会怎样？​

1、后端服务现象​

1、连接建立失败（握手阶段崩溃）​

  • 现象：大量浏览器发起 TCP 连接请求后，服务器返回ECONNREFUSED错误，或请求超时。
  • 原理：
    • TCP 半连接队列溢出：服务器的syn_backlog队列（存储三次握手未完成的连接）默认大小通常为几百到几千（如 Linux 默认/proc/sys/net/ipv4/tcp_max_syn_backlog约 1024），100 万并发连接会瞬间填满队列，新连接被直接丢弃。
    • 端口资源耗尽：服务器响应连接时需为每个连接分配源端口（范围通常 1024~65535），单台服务器每秒最多创建约 6 万新端口（受限于 TCP 四次挥手的 TIME_WAIT 状态），无法支撑百万级连接。

2、服务器资源耗尽（CPU / 内存崩溃）​

  • 现象：服务器 CPU 使用率 100%，内存溢出，服务进程被操作系统 kill（OOM Killer）。
  • 原理：
    • 线程 / 进程资源爆炸：若服务采用传统 “一连接一线程” 模型（如 Tomcat 默认），100 万连接需 100 万个线程，每个线程默认栈内存约 1MB，仅内存就需 1TB，远超普通服务器配置。
    • 上下文切换过载：CPU 忙于线程调度（每次切换需纳秒级开销），实际处理请求的时间被抢占，导致系统 “假死”。

3、文件描述符耗尽（Linux 系统瓶颈）​

  • 现象：服务抛出Too many open files错误，无法接收新连接。
  • 原理：Linux 系统每个进程的文件描述符（FD）默认限制约 1024（可通过ulimit -n查看），即使调整到百万级（如ulimit -n 1000000），内核处理百万级 FD 的开销也会导致系统崩溃（如epoll监听百万 FD 时，事件扫描效率骤降）。

4、 网络带宽瓶颈（流量堵塞）​

  • 现象：请求响应延迟飙升，大量数据包丢失，浏览器显示 “网络错误”。
  • 原理：假设每个请求包大小 1KB，100 万并发请求的入口带宽约为 8Gbps（100 万 ×1KB×8bit），远超普通服务器千兆网卡（1Gbps）的承载能力，导致网络拥塞。

5、下游服务级联故障（数据库 / 缓存崩溃）​

  • 现象：后端服务依赖的数据库、Redis 等抛出连接拒绝错误，服务整体瘫痪。
  • 原理：
    • 数据库连接池默认大小通常为几十到几百（如 MySQL 默认max_connections约 151），百万级请求会瞬间耗尽连接池，导致 SQL 请求堆积。
    • 缓存服务（如 Redis）虽支持高 QPS（单节点 10 万 +），但百万级并发会触发网络超时或请求队列积压，导致缓存失效，进而引发数据库 “雪崩”。

2、不通架构下差异​

1、传统单体架构

  • 崩溃速度：秒级内 CPU 和内存耗尽，服务直接退出。
  • 根本原因：同步阻塞模型下，连接数与线程数强绑定，资源消耗线性增长。

2、异步非阻塞架构

  • 现象：可支撑更高连接数（如 Nginx 单节点可维护 10 万 + 长连接），但请求处理耗时会显著增加（如事件循环队列积压）。
  • 瓶颈转移：从线程资源转向 CPU 事件处理能力和网络 I/O 带宽。

3、分布式集群架构（多节点 + 负载均衡）

  • 现象：若集群节点数不足（如 10 台服务器），负载均衡器（如 LVS）首先因连接数过载崩溃，或请求被均匀分发后各节点同时耗尽资源。
  • 关键限制：负载均衡器自身的连接处理能力（如 LVS 单节点通常支撑 10 万级连接）和集群规模（需至少 100 台节点才可能分散百万请求）。

3、 底层技术限制总结​

层面限制因素百万级并发下的瓶颈表现
网络层TCP 协议栈处理能力、端口数量、带宽连接握手失败、数据包丢失
操作系统文件描述符限制、进程 / 线程资源、CPU 调度无法创建新连接、系统因 OOM 崩溃
应用层连接模型（同步 / 异步）、框架并发能力传统框架直接崩溃，异步框架事件循环阻塞
存储层数据库 / 缓存连接池、I/O 吞吐量连接池耗尽、磁盘 I/O 被打满

4、现实中的防御机制（为何不会真的崩溃？）​

  1. 前端限流：浏览器默认并发连接数有限（如 Chrome 每个域名默认 6 个连接），100 万个浏览器需百万个不同域名或人工修改配置，现实中几乎不可能。
  2. 中间件防护：负载均衡器（如 Nginx）可配置limit_conn限流（如单 IP 限制 100 连接），防止恶意攻击。
  3. 操作系统优化：调整内核参数（如增大tcp_max_syn_backlog、修改 TIME_WAIT 回收策略）可提升连接处理能力，但无法突破硬件极限。

5、百万级并发的本质挑战​

百万级浏览器请求的核心问题不是 “后端服务” 本身，而是底层基础设施的物理限制：

  • 硬件层面：需万兆网卡、TB 级内存、分布式集群（数百节点）才能支撑；
  • 软件层面：需全链路异步架构（如 Nginx + Go + 分布式数据库）和多级限流策略（如网关限流、应用限流、存储限流）

Go 服务如何处理百万并发请求？​