epoll模型设计海量级连接服务器

最近在参与一个海量级（20000以上）远程连接的服务器设计，由于用户要求的硬件平台仅限于Linux，因此选择了epoll模型来实现对海量客户端连接的处理。

先聊一下epoll模型的基本情况。（一般来说，非海量级客户端连接的服务器，可能用不到epoll模型。一方面是由于epoll模型不能跨平台，另一方面初学者面露难色）。使用到epoll_create，epoll_ctl，epoll_wait，close 4个函数。

Epoll较之select优越的点，有两个方面：

1）select操作的socket对象的集合，要受到FD_SETSIZE的限制，各平台的缺省值也不一样（Windows上是64，AIX、Linux、HP、Solaris上为1024或2048不等）；而epoll操作的socket对象集合仅受系统的句柄限制，一般来说，可以达到65535

2）select和epoll的核心实现机制不同。Select实现中，kernel每次都要遍历FD_SET中的socket，检测是否可读，花费的时间和FD_SET中的socket个数成正比；epoll实现中，当有socket可读时，由核心激活epoll订阅的一个事件，因此节省了sys cpu从而节约了资源，自然就提高了效率

epoll模型提供了二种工作模式：

1）Edge Triggered (ET)

ET是高速工作方式，只支持no-block socket。当IO事件发生时内核通知事件后不再发送更多的通知，直到用户执行的操作导致那个socket（或文件描述符）事件的改变，也就是说如果用户不对socket（或文件描述符）进行IO操作，那么内核也不会再通知事件。

2）Level Triggered (LT)

LT是缺省的工作方式，同时支持block和no-block socket。内核通知事件一个文件描述符是否就绪了，然后可以对这个就绪的fd进行IO操作。如果用户不作任何读、写操作，内核还是会继续通知事件的。

更详细的epoll定义或信息，参照相关网络信息或书籍即可。下面，我来描述一下，这个需求中的epoll模型的设计。

一、业务需求如下图，要求满足高并发、高性能、高可靠等属性。

二、流程设计：

1） 主进程

1） Net_recv_thfunc工作线程

Handle_NetRecv函数流程

2） Net_send_thfunc工作线程

Epoll模型使用中，注意以下几个点：

1）避免多个线程操作同一个epoll对象，否则会出现惊群现象，即当一个可读EPOLLIN或EPOLLOUT事件到达时，所有线程都返回这个事件，但只有一个线程真正能拿到这个事件，其他的线程将返回EWOULDBLOCK

2）操作epoll对象的线程和操作socket的线程是否分开，应视后续的处理效率而定。如果接受到socket数据的后续处理性能高，则可以在同一线程里来搞定；否则，需要创建另一类线程池，来参与socket数据的后续处理。

3）毕竟，一个进程内的句柄数也有限。如果要适应更加海量的客户端连接，可采取在同一台设备（硬件资源足够的情况下）或多台设备上，部署多套“接入管理Server”。