最近在参与一个海量级(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”。
转载于:https://blog.51cto.com/no001/1314648