什么是C10K问题
1W个客户端连接上一个server，客户不定时的发送请求。
I/O策略
软件架构
1.单线程解决多重I/O调用
不要使用阻塞/同步的调用，如果非要这么做，那就采用多进程或者多线程来并发处理。
使用非阻塞的调用和就绪通知策略，当下一个I/O可用时通知调用者。适用于套接字I/O，而不是磁盘I/O.
使用异步的调用和通知策略，当下一个I/O可用时通知调用者，适用于磁盘I/O和套接字I/O。
2.如何控制服务每个客户端的代码
每一个client对应一个服务端进程，每一个进程保存client的一个状态机。
I/O方案
1.每个线程处理多个客户端请求，使用非阻塞I/O和水平触发通知策略（同步非阻塞轮询）
水平触发通知策略
当I/O触发可读写的时候，如果调用者没有及时处理，下一次检查I/O状态的时候仍然会通知调用者。
垂直触发通知策略
当I/O触发可读写的时候，如果调用者没有及时处理，下一次检查I/O状态的时候就不再通知调用者，和水平触发通知策略不同的是，只有在I/O状态由不可用变为可用的时候才会通知调用者。
设置文件描述符为非阻塞，告诉epoll想要关注哪些事件，内核将会检测哪些fd可用并通知调用者，不管调用者做了什么，只要fd是可用的，就一直通知调用者。
瓶颈：如果要读的页不在core中，那从磁盘中read和sendfile是一个重要的瓶颈。对内存映射文件和磁盘文件句柄设置非阻塞模式是没有什么意义的，当服务器第一次需要进行磁盘I/O时将会阻塞，所有的client请求都必须等待。
2.每个线程处理多个客户端请求，使用非阻塞I/O和就绪改变通知
就绪改变通知，你交给内核一个文件句柄，当文件描述符从不就绪改变成就绪时，内核会通知你。在文件描述符从就绪状态改变为非就绪状态之前不会再发送通知，也就是说，想要再次触发通知，除非你做了某些操作使文件描述符进入非就绪状态，比如在send、recv、accept收到了EWOULDBLOCK错误。
当使用就绪改变通知的时候，必须准备好应对闲杂事件，因为一个通用的实现是当收到任何包的时候都会通知，而不是当文件描述符就绪的时候才通知。
使用就绪改变通知会减少编程错误的容忍度，如果你漏处理了一个连接上的任意一个事件，连接上的所有消息都被阻塞。
3.每个线程处理多个客户端请求，使用异步I/O
目前还不是很流行，可能是比较少的操作系统支持异步I/O，也可能是使用异步I/O需要重构现有的代码。异步I/O把一个signal和value关联到每一个I/O操作上，signal和value被实时的入队和发送到用户进程。LINUX目前有aio的实现。
使用异步I/O也无法避免打开磁盘文件的阻塞过程，一个好的建议是在另外的线程打开磁盘文件。
4.每个server线程处理一个client
缺点是每个线程要保持一定的线程堆栈开销，如果启动数百个线程，开销还是相当可观的。
5.把server代码编译到内核中
其他的一些手段
zero-copy
sendfile API实现了网络的zero-copy
原文