The C10K problem
编写连接数巨大的高负载服务器程序时，经典的多线程模式和select模式都不再适用。应当抛弃它们，采用epoll/kqueue/dev_poll来捕获I/O事件。最后简要介绍了AIO。网络服务在处理数以万计的客户端连接时，往往出现效率低下甚至完全瘫痪，这被称为 C10K问题。随着互联网的迅速发展，越来越多的网络服务开始面临C10K问题，作为大型 网站的开发人员有必要对C10K问题有一定的了解。本文的主要参考文献是 http://www.kegel.com/c10k.html。 C10K问题的最大特点是：设计不够良好的程序，其性能和连接数及机器性能的关系往往 是非线性的。举个例子：如果没有考虑过C10K问题，一个经典的基于select的程序能在 旧服务器上很好处理1000并发的吞吐量，它在2倍性能新服务器上往往处理不了并发2000的吞吐量。 这是因为在策略不当时，大量操作的消耗和当前连接数n成线性相关。会导致单个任务的资源消耗和当前连接数的关系会是O(n)。而服务程序需要同时对数以万计的socket进 行I/O处理，积累下来的资源消耗会相当可观，这显然会导致系统吞吐量不能和机器性 能匹配。为解决这个问题，必须改变对连接提供服务的策略。
主要有两方面的策略：1.应用软件以何种方式和操作系统合作，获取I/O事件并调度多 个socket上的I/O操作；2. 应用软件以何种方式处理任务和线程/进程的关系。前者主 要有阻塞I/O、非阻塞I/O、异步I/O这3种方案，后者主要有每任务1进程、每任务1线 程、单线程、多任务共享线程池以及一些更复杂的变种方案。常用的经典策略如下：
1. Serve one client with each thread/process, and use blocking I/O 这是小程序和java常用的策略，对于交互式的长连接应用也是常见的选择(比如BBS)。 这种策略很能难足高性能程序的需求，好处是实现极其简单，容易嵌入复杂的交互逻 辑。Apache、ftpd等都是这种工作模式。
2. Serve many clients with single thread, and use nonblocking I/O and readiness notification 这是经典模型，datapipe等程序都是如此实现的。优点在于实现较简单，方便移植，也 能提供足够的性能；缺点在于无法充分利用多CPU的机器。尤其是程序本身没有复杂的 业务逻辑时。
3. Serve many clients with each thread, and use nonblocking I/O and readiness notification 对经典模型2的简单改进，缺点是容易在多线程并发上出bug，甚至某些OS不支持多线程 操作readiness notification。
4. Serve many clients with each thread, and use asynchronous I/O 在有AI/O支持的OS上，能提供相当高的性能。不过AI/O编程模型和经典模型差别相当 大，基本上很难写出一个框架同时支持AI/O和经典模型，降低了程序的可移植性。在 Windows上，这基本上是唯一的可选方案。
本文主要讨论模型2的细节，也就是在模型2下应用软件如何处理Socket I/O。
select 与 poll
最原始的同步阻塞 I/O 模型的典型流程如下：
同步阻塞 I/O 模型的典型流程 从应用程序的角度来说，read 调用会延续很长时间，应用程序需要相当多线程来解决 并发访问问题。同步非阻塞I/O对此有所改进： 经典的单线程服务器程序结构往往如下：
<div class="dp-highlighter"><div class="bar"><div class="tools">
页:
[1]