什么是 C10K 问题？如何解决？

简化版

C10K 问题指单台服务器如何同时处理 1 万（10K）个并发连接。传统的「一连接一线程/进程」模型扛不住——1 万连接就要 1 万个线程，光线程栈就要约 10GB 内存，加上海量线程的上下文切换开销，服务器直接崩溃。解决的核心是用 IO 多路复用（epoll）+ 少量线程：一个线程用 epoll 监控海量连接，只处理有事件的那些，让「连接数」和「线程数」解耦。这也是 Reactor 模型和现代高性能服务器（Nginx/Redis/Netty）的由来。

详细版

问题的由来：早期服务器用「一连接一线程」或「一连接一进程」处理并发。连接数少时没问题，但当目标是同时处理 1 万连接时：

内存爆炸：每个线程默认栈约 1MB，1 万线程 ≈ 10GB 内存，还没算别的；
上下文切换开销爆炸：CPU 要在 1 万个线程间来回切换，大量时间浪费在切换而非干活上；
大部分线程在阻塞等待：这些线程多数时间阻塞在 read 上等数据，白白占着资源却没做事。

「一连接一线程」的问题是连接数和线程数绑定——连接涨，线程跟着涨，资源线性爆炸。

解决思路：用 IO 多路复用把「连接数」和「线程数」解耦——

用 epoll 让一个线程同时监控成千上万个连接的 fd；
只有就绪的连接（有数据可读写）才去处理，空闲连接不占线程；
少数几个线程（通常和 CPU 核数相关）就能撑起海量连接。

配合 Reactor 模型组织事件处理、非阻塞 IO 避免线程被单个连接卡住，就能高效解决 C10K。

完整版教学

一、C10K 的本质：连接数与线程数的解耦

C10K 这个名字（Concurrent 10K connections）代表的是一类问题——如何让单机撑起海量并发连接。它的本质矛盾是：

传统模型：连接和线程一一绑定，1 个连接配 1 个线程。于是 N 个连接 = N 个线程，资源随连接数线性膨胀，很快触顶；
要解决它：必须打破这个绑定——让少量线程管理大量连接，「连接数」和「线程数」不再挂钩。

抓住这个「解耦」，就抓住了 C10K 及所有高并发网络编程的核心思想。而实现解耦的关键工具，就是 IO 多路复用（epoll）。

二、为什么「一连接一线程」扛不住

具体看传统模型为什么在 1 万连接时崩溃：

内存：线程栈是主要开销，每个约 1MB，1 万线程约 10GB，机器内存吃不消；
上下文切换：操作系统在大量线程间切换需要保存/恢复寄存器、刷新缓存，1 万线程下 CPU 大量时间耗在切换上，真正处理请求的时间反而少；
资源利用低：网络连接大部分时间是空闲的（在等用户输入、等数据），对应的线程就阻塞在 read 上干等——占着线程却没干活，极度浪费。

最后一点是关键：连接虽多，但同一时刻真正活跃（有数据收发）的往往只是少数。传统模型却给每个连接（不管活不活跃）都配了线程，浪费在了大量空闲连接上。

三、epoll：一个线程管海量连接

IO 多路复用（epoll）正是针对「大量连接、少数活跃」这个特点设计的（详见「epoll 原理」那道题）：

把所有连接的 fd 注册到 epoll；
epoll_wait 只返回当前就绪（有数据收发）的少数 fd；
一个线程只处理这些就绪的 fd，处理完继续 epoll_wait。

于是无论有 1 万还是 100 万个连接，只要同时活跃的是少数，一个线程就能高效轮转处理。连接数和线程数彻底解耦——连接可以海量增长，线程数保持很小（和 CPU 核数相关）。这就是 epoll 解决 C10K 的核心。

四、完整方案：epoll + Reactor + 非阻塞 + 多核

真正的高并发服务器不只用 epoll，而是一套组合拳：

epoll（IO 多路复用）：一个线程监控海量连接，找出就绪的；
非阻塞 IO：读写用非阻塞，避免单个连接的 IO 把线程卡住（尤其 ET 模式必须非阻塞，详见「epoll LT/ET」那道题）；
Reactor 模型：把「事件监听」和「事件处理」组织起来，事件就绪就分发给对应 Handler（详见「Reactor 模型」那道题）；
多线程/多 Reactor 利用多核：主从 Reactor 把连接接受、IO 读写、业务处理分摊到多个线程/多核（如 Netty 的 boss/worker 线程组），进一步提升吞吐；
业务与 IO 分离：耗时业务丢线程池，别阻塞 IO 线程。

这套方案就是 Nginx、Redis、Netty 等高性能服务器的共同架构，C10K 早已被它们轻松解决。

五、从 C10K 到 C10M

C10K 在 epoll 出现后已不是问题，业界又提出了 C10M（同时处理 1000 万连接）的更高挑战。到这个量级，光靠 epoll + Reactor 还不够，瓶颈转移到了内核本身——内核协议栈的处理、中断、内存拷贝成了限制。

C10M 的解法更激进：内核旁路（Kernel Bypass）——用 DPDK、用户态协议栈等技术绕过内核，让网络数据直接在用户态处理，消除内核开销。这属于极致高性能领域（如高频交易、大型网关），了解思路即可：当连接数量级再上一个台阶，优化对象就从「应用模型」转向了「内核开销」。

六、常见误区与追问

考点	正确口径
C10K	单机同时处理一万个并发连接的问题
瓶颈	线程/进程开销、阻塞 IO、内存、文件描述符、内核调度
解决方向	非阻塞 IO、IO 多路复用、事件驱动、连接状态轻量化

1 thread per connection:
10000 connections -> 10000 threads -> high memory and context switch

event loop:
1 or few threads -> monitor many sockets -> dispatch ready events

C10K 的核心不是“请求数一万”，而是大量连接同时存在时，阻塞线程模型撑不住。

误区：C10K 只靠提高 CPU 就能解决。 CPU 只是资源之一，线程栈内存、上下文切换、阻塞 IO 和 fd 限制都会成为瓶颈。
误区：每个连接一个线程最直观所以最好。 连接多但活跃事件少时，大量线程会浪费内存并放大调度成本。
误区：epoll 出现后 C10K 就完全不是问题。 epoll 降低事件通知成本，但应用处理、协议解析、内存管理和后端依赖仍可能成为瓶颈。
追问：C10K 和 QPS 是一回事吗？ 不是，C10K 强调并发连接规模，QPS 强调单位时间请求处理量。
追问：为什么非阻塞 IO 有帮助？ 线程不会卡在单个连接读写上，可以在事件就绪时再处理。
追问：现代系统还会遇到什么升级版问题？ 会遇到 C100K、C1M，以及 TLS、长连接、内存和业务后端带来的新瓶颈。

七、加强记忆

C10K 是单机同时处理 1 万并发连接的问题。传统「一连接一线程」把连接数和线程数绑定，1 万连接=1 万线程，内存（约 10GB）和上下文切换爆炸，且大量线程阻塞空等浪费。解决核心是用 IO 多路复用（epoll）解耦连接数与线程数——一个线程监控海量连接、只处理就绪的少数，配合非阻塞 IO + Reactor + 多核。这是 Nginx/Redis/Netty 的架构。更高的 C10M（千万连接）则靠内核旁路（DPDK）绕过内核开销。

简化版

详细版