C10K和C10M
计算机领域的很多技术都是需求推动的，上世纪90年代，由于互联网的飞速发展，网络服务器无法支撑快速增长的用户规模。1999年，Dan Kegel提出了著名的C10问题：一台服务器上同时处理10000个客户网络连接。10000个网络连接并不会发送请求到服务器，有些连接并不活跃，同一时刻，只有极少的部分连接发送请求。不同的服务类型，每个连接发送请求的频率也不相同，游戏服务器的连接会频繁的发送请求，而Web服务器的连接发送请求的频率就低很多。无论如何，根据经验法则，对于特定的服务类型，连接越多，同一时刻发送请求的连接也越多。
时至今日，C10K问题当然早已解决，不仅如此，一台机器能支撑的连接越来越多，后来提出了C10M问题，在一台机器上支撑1000万的连接，2015年，MigratoryData在单机承载12M的连接，解决了C10M问题。
本文先回顾C10问题的解决方案，再探讨如何构建支撑C10M的应用程序，聊聊其中涉及的各种技术。
C10K问题的解决
时间退回到1999年，当时要实现一个网络服务器，大概有这样几种模式
简单进程/线程模型
这是一种非常简单的模式，服务器启动后监听端口，阻塞在accept上，当新网络连接建立后，accept返回新连接，服务器启动一个新的进程/线程专门负责这个连接。从性能和伸缩性来说，这种模式是非常糟糕的，原因在于
进程/线程创建和销毁的时间，操作系统创建一个进程/线程显然需要时间，在一个繁忙的服务器上，如果每秒都有大量的连接建立和断开，采用每个进程/线程处理一个客户连接的模式，每个新连接都要创建创建一个进程/线程，当连接断开时，销毁对应的线程/进程。创建和销毁进程/线程的操作消耗了大量的CPU资源。使用进程池和线程池可以缓解这个问题。
内存占用。主要包含两方面，一个是内核数据结构所占用的内存空间，另外一个是Stack所占用的内存。有些应用的调用栈很深，比如Java应用，经常能看到几十上百层的调用栈。
上下文切换的开销。上下文切换时，操作系统的调度器中断当前线程，选择另外一个可运行的线程在CPU上继续运行。调度器需要保存当前线程的现场信息，然后选择一个可运行的线程，再将新线程的状态恢复到寄存器中。保存和恢复现场所需要的时间和CPU型号有关，选择一个可运行的线程则完全是软件操作，Linux 2.6才开始使用常量时间的调度算法。 以上是上下文切换的直接开销。除此之外还有一些间接开销，上下文切换导致相关的缓存失效，比如L1/L2 Cache，TLB等，这些也会影响程序的性能，但是间接开销很难衡量。
有意思的是，这种模式虽然性能极差，但却依然是我们今天最常见到的模式，很多Web程序都是这样的方式在运行。
另外一种方式是使用select/poll，在一个线程内处理多个客户连接。select和poll能够监控多个socket文件描述符，当某个文件描述符就绪，select/soll从阻塞状态返回，通知应用程序可以处理用户连接了。使用这种方式，我们只需要一个线程就可以处理大量的连接，避免了多进程/线程的开销。之所以把select和poll放在一起说，原因在于两者非常相似，性能上基本没有区别，唯一的区别在于poll突破了select 1024个文件描述符的限制，然而当文件描述符数量增加时，poll性能急剧下降，因此所谓突破1024个文件描述符实际上毫无意义。select/poll并不完美，依然存在很多问题：
每次调用select/poll，都要把文件描述符的集合从用户地址空间复制到内核地址空间
select/poll返回后，调用方必须遍历所有的文件描述符，逐一判断文件描述符是否可读/可写。
这两个限制让select/poll完全失去了伸缩性。连接数越多，文件描述符就越多，文件描述符越多，每次调用select/poll所带来的用户空间到内核空间的复制开销越大。最严重的是当报文达到，select/poll返回之后，必须遍历所有的文件描述符。假设现在有1万个连接，其中只一个连接发送了请求，但是select/poll就要把1万个连接全部检查一遍。
FreeBSD 4.1引入了kqueue，此时是2000年7月，而在Linux上，还要等待2年后的2002年才开始引入kqueue的类似实现: epoll。epoll最初于 2.5.44进入Linux kernel mainline，此时已经是2002年，距离C10K问题提出已经过了3年。
epoll是如何提供一个高性能可伸缩的IO多路复用机制呢？首先，epoll引入了epoll instance这个概念，epoll instance在内核中关联了一组要监听的文件描述符配置：interest list，这样的好处在于，每次要增加一个要监听的文件描述符，不需要把所有的文件描述符都配置一次，然后从用户地址空间复制到内核地址空间，只需要把单个文件描述符复制到内核地址空间，复制开销从O(n)降到了O(1)。
注册完文件描述符后，调用epoll_wait开始等待文件描述符事件。epoll_wait可以只返回已经ready的文件描述符，因此，在epoll_wait返回之后，程序只需要处理真正需要处理的文件描述符，而不用把所有的文件描述符全部遍历一遍。假设在全部N个文件描述符中，只有一个文件描述符Ready，select/poll要执行N次循环，epoll只需要一次。
epoll出现之后，Linux上才真正有了一个可伸缩的IO多路复用机制。基于epoll，能够支撑的网络连接数取决于硬件资源的配置，而不再受限于内核的实现机制。CPU越强，内存越大，能支撑的连接数越多。