Morning Star

c10k问题原文请参考 http://www.kegel.com/c10k.html

本文仅仅是个开始，希望同学们评论，或增加新的注意点。

五种处理并发请求的模式：
serve one client with each server thread, and use blocking I/O
a. 将每个fd交给一个线程处理，用阻塞io

Serve many clients with each thread, and use nonblocking I/O and level-triggered readiness notification
b. select/pool +多线程+非阻塞io

Serve many clients with each thread, and use nonblocking I/O and readiness change notification
c. epool +多线程 +非阻塞io+边沿触发

Serve many clients with each server thread, and use asynchronous I/O
d. aio+多线程

Build the server code into the kernel
e. 将服务器代码放到内核中

注意点：
1. a方案的缺点是浪费资源，因为有多少请求就有多少线程，每个线程有自己的栈，线程在被阻塞时也会占用一定内存。

2. b方案的缺点有：
FD_SETSIZE宏大小的限制；
并行处理请求太多的话，需要遍历FD SET，浪费cpu；
SELECT可能需要增加一个管道，在有新fd来时候向管道发送数据，让select返回并把新的fd添加到SET，增加了一点点编程复杂度；

3. epoll 相对于select来说，通过设置回调，不需要遍历，能直接得到可读的fd；

4. aio相对于epoll来说更进一步，直接把用户空间的内存mmap到内核空间，这样在用户得到通知的时候，buffer里已经有数据了，不用再像epool那样从fd里读数据，减少了一次读数据的时间；

5. 方案的好坏不是绝对的，传说如果活动的fd数量足够多（例如>60%）epool性能会没有pool好，也就是说这个时候设置回调没有直接遍历来得快。

6.一般对于web服务器来说，活动fd数量应该不会占太大比例。

7.一般select的fd都会设置成非阻塞，因为fd可读只是一个hint，并不是一定就可以读的。

8.有两种触发方式，水平触发和边沿触发。水平触发指的是只要这个fd还有数据可读，就会再次通知用户；边沿触发只会通知一次。