在linux的网络编程中,经常使用多线程处理高并发的问题,然而linux系统对线程数量是有限制的,更重要的是线程的调度有系统开销的,在客户端数量庞大时,这将是无法接受的问题;另一种处理高并发的方法是使用select来做事件触发,select实现中,它是采用轮询来处理的,轮询的fd数目越多,耗时越多,而且,在linux/posix_types.h头文件有这样的声明:
#define __FD_SETSIZE 1024
表示select最多同时监听1024个fd,当然,可以通过修改头文件再重编译内核来扩大这个数目,但这并不是很好的解决办法。
为了解决这一问题,Linux内核为处理大批量文件描述符而作了改进的poll,是Linux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率;获取事件的时候,它无须遍历整个被侦听的描述符集,只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll提供了水平触发(LevelTriggered)和边缘触发(EdgeTriggered)两种模式,具体在后续介绍。
epoll的接口非常简单,一共就三个函数:
1. int epoll_create(int size);
创建一个epoll的句柄,size用来告诉内核这个监听的数目一共有多大。需要注意的是epoll也是一个句柄,不再使用时需要主动调用close关闭,否则会导致句柄资源泄露。
2. int epoll_ctl(int epfd, int op, int fd,struct epoll_event *event);
epoll的事件注册函数
第一个参数是epoll句柄,epoll_create()的返回值;
第二个参数表示动作,用三个宏来表示:
EPOLL_CTL_ADD:注册新的fd到epfd中;
EPOLL_CTL_MOD:修改已经注册的fd的监听事件;
EPOLL_CTL_DEL:从epfd中删除一个fd;
第三个参数是需要监听的fd;
第四个参数是监听的事件,用structepoll_event结构表示,具体如下:
typedef union epoll_data {
void *ptr;
int fd;
__uint32_t u32;
__uint64_t u64;
} epoll_data_t;
struct epoll_event {
__uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};
events可以是以下几个宏的集合:
EPOLLIN :表示对应的文件描述符可以读(包括对端SOCKET正常关闭);
EPOLLOUT:表示对应的文件描述符可以写;
EPOLLPRI:表示对应的文件描述符有紧急的数据可读(这里应该表示有带外数据到来);
EPOLLERR:表示对应的文件描述符发生错误;
EPOLLHUP:表示对应的文件描述符被挂断;
EPOLLET: 将EPOLL设为边缘触发(Edge Triggered)模式,这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT:只监听一次事件,当监听完这次事件之后,如果还需要继续监听这个socket的话,需要再次把这个socket加入到EPOLL队列里
3. int epoll_wait(int epfd, structepoll_event * events, int maxevents, int timeout);
等待事件的产生,类似于select()调用。参数events用来从内核得到事件的集合,maxevents告之内核这个events有多大,这个 maxevents的值不能大于创建epoll_create()时的size,参数timeout是超时时间(毫秒,0会立即返回,-1将不确定,也有说法说是永久阻塞)。该函数返回需要处理的事件数目,如返回0表示已超时。
关于水平触发(LevelTriggered)和边缘触发(EdgeTriggered)两种模式;水平触发模型下只要缓冲区有数据就会不断获得通知;边缘触发模式仅当状态发生变化的时候才获得通知,可以理解为缓冲区由0变为1或者由1变为0时才会获得通知。水平触发事件不会丢弃,而边缘触发处理更高效。
服务器的开发没有固定的高效框架,都需要根据服务器开发需要注意的要点,结合具体需求实际定制,一些需要注意的的点整理如下:
1.尽量使用分布式、去中心化、无状态化、一致性哈希等;
2.尽量少的线程切换,尽量少的共享冲突,尽量无锁;
3.尽量没有等待时间片的线程,逻辑尽量简化,避免不必要的封装和转发;
4.不要在epoll_wait()线程中用太长时间处理非epoll_wait()的事情;
5.能用atomic的就不要用mutex;
6.数据库尽量采用分布式,采用好的数据路由中间层服务,好的集群管理器数据库,尽量分库分表,建议使用Hash分表,尽量避免按区段分表。
7.如果非要有中心,请尽量选折以下两个方案:
a. 中心如果很简单,请确保在崩溃/杀死后,1秒钟内能立刻复活启动~~~
b. 中心改为管理集群,自动选举主核心。当原主核心失效后,新的核心自动接管当前集群网络。
8.不要使用XML,如果文本,使用JSON。如果二进制,请使用JSON对应的二进制化协议。