一万个并发会话是一个有实质意义的门槛。它将一个普通的 Web 应用与必须承载真实负载、容忍流量突发、并能从组件故障中干净恢复的基础设施区分开来。要达到这一水平的规格规划，绝不仅仅是挑选一颗核心数足够的 CPU。
本文将逐一讲解 CPU、内存、网络和存储方面的决策，这些决策决定了服务器是能从容应对 10,000 个并发会话，还是在第一波流量高峰下就崩溃。
从工作负载模型入手
“并发会话”对不同的应用意味着不同的东西。一个会话可能是轮询 API 的已登录用户、持续推送事件的 WebSocket 连接，也可能是一个在毫秒内完成的、有数据库支撑的 HTTP 请求。资源消耗特征会因以下因素而发生巨大变化：
- 会话时长与空闲时间
- 每个会话每秒的请求数
- 工作负载是 CPU 受限、内存受限还是 I/O 受限
- 对持久化、缓存或实时状态的需求
一个维持 10,000 个开放套接字的聊天服务器可能只需要很少的 CPU，但需要大量内存。一个拥有 10,000 个活跃任务的视频处理 API 则需要 GPU 或大量 CPU 核心以及高速存储。在选择硬件之前，务必先对工作负载建模。
CPU 规格规划
对于这一规模下的典型 Web 或 API 工作负载，应预留足够的余量，使单个 CPU 插槽就能吸收一次流量突发或部分故障。实用建议：
- 估算峰值每秒请求数以及每个请求的 CPU 耗时
- 将持续利用率控制在不超过 60–70%，避免突发流量使核心饱和
- 对延迟敏感型工作优先选择更高主频；对并行或批处理任务优先选择更多核心
- 将日志记录、健康检查和垃圾回收等后台任务的开销考虑在内
许多承载 10,000 个会话的 Web 应用在配备中端处理器的双路服务器上运行得很从容，但唯一可靠的答案来自针对您实际应用进行的负载测试。
内存规划
在并发场景下，内存通常是第一个瓶颈。每个打开的连接、每个缓存对象和每个活跃进程都会消耗 RAM。请考虑：
- 每个会话的内存占用，包括缓冲区和状态数据
- 应用堆内存大小与垃圾回收行为
- 为获得可接受的延迟而必须驻留在内存中的数据库或缓存工作集（working set）
- 高连接数带来的操作系统与内核开销
在预期峰值负载之上，至少预留 25–50% 的空闲内存。并发场景下的内存交换（swap）会摧毁延迟，并可能级联引发技术栈其他环节的故障。
网络与存储
网络
在大负载的情况下，10,000 个并发会话很容易打满一条 1 Gbps 链路。绑定（bonding）的 10 GbE 或 25 GbE 接口是生产服务器常见的起点。实测出站（egress）与入站流量，然后选择具有足够余量、并为您的工作负载提供合适中断扩展（interrupt scaling）能力的网卡。
存储
任何处理同步写入或随机 I/O 的路径都应使用 NVMe SSD。RAID 1 或 RAID 10 配置可以在不承受奇偶校验型 RAID 写入惩罚的情况下防范磁盘故障。如果工作负载以读为主，在扩充存储硬件之前，请先考虑引入缓存层。
服务器规格规划清单
| 组件 | 规划原则 |
|---|---|
| CPU | 对峰值负载建模，然后将最大持续利用率目标定为 60–70% |
| 内存 | 按工作集大小规划，并预留 25–50% 余量 |
| 网络 | 使用 10 GbE 或更高速率，并以实测数据确定余量 |
| 存储 | 同步/随机 I/O 使用 NVMe；冗余采用 RAID 1 或 RAID 10 |
| 冗余 | 双电源、双网卡，并在上线生产前完成故障转移测试 |
