基本概念:子进程继承父进程环境和上下文的大部分内容的拷贝,其中就包括文件描述符表。
父进程fork出来的子进程,复制父进程的文件描述符。这些文件描述符fd是独立的,但是文件描述符指向的系统文件表项是唯一的,即是 struct file本身唯一。
同理,fork得到的子进程和父进程共享同一个socket(套接字代表文件)。fd与文件关联,通过绑定struct sockaddr套接字地址空间,跟特定的ip和端口绑定在一起。
所以在子进程中accept(listen,....),虽然listen在不同进程中,代表不同的进程的文件描述符,但是这个文件描述符对应的套接字是一样的。又因为套接字指定了套接字地址,所以可以监听来自客户端的连接。
惊群的服务器的模型:
父进程listen之后,子进程堵塞在accept函数这里,这就是惊群发生的根本原因
惊群现象:
当父进程绑定一个端口监听socket,然后fork出多个子进程,子进程们开始循环处理(比如accept)这个socket。每当用户发起一个TCP连接时,多个子进程同时被唤醒,然后其中一个子进程accept新连接成功,余者皆失败,重新休眠。
惊群现象的危害:
在较老的unix系统中,当有连接到来时,accept()在每个阻塞在这的进程里被唤醒。但是,只有这些进程中的一个能够真正的accept这个连接,其他的进程accept将返回EAGAIN,惊群造成的结果是系统对用户进程/线程频繁的做无效的调度、上下文切换,系统系能大打折扣。
解决:
我们不能只用一个进程去accept新连接么?然后通过消息队列等同步方式使其他子进程处理这些新建的连接,这样惊群不就避免了?没错,惊群是避免了,但是效率低下,因为这个进程只能用来accept连接。对多核机器来说,仅有一个进程去accept,这也是程序员在自己创造accept瓶颈。所以,我仍然坚持需要多进程处理accept事件。
其实,在linux2.6内核上,accept系统调用已经不存在惊群了(至少我在2.6.18内核版本上已经不存在)。大家可以写个简单的程序试下,在父进程中bind,listen,然后fork出子进程,所有的子进程都accept这个监听句柄。这样,当新连接过来时,大家会发现,仅有一个子进程返回新建的连接,其他子进程继续休眠在accept调用上,没有被唤醒。(没有被唤醒,继续休眠)
解决方法: