epool惊群问题的一个解决方案(利用SO_REUSEPORT)

    在前段时间公司开发的一个项目中，需要使用多个进程监听同一个端口提高性能，这样的需求需要我们解决惊群问题。

    在早些时候，我们是不能在多个子进程中listen、bind同一个socket端口的。通常的做法会在主进程中对端口进行listen、bind，然后把它同时扔进每个子进程维护的epool池中。
    在这种情况下，当一个客户端请求来到服务端，会导致多个子进程的epool监听同时被唤醒，这就是我们通常所说的epool惊群问题。 在上述背景下，一般有两种情况，虽然不是我们今天文章的主题，也介绍一下。

     无视惊群
    这是lighttpd的解决思路。主要处理流程就是放任每一个子进程的epool监听都被唤醒，然后同时进行accpet()操作。在这种情况下只有一个accept操作会成功(前提是socket被设置为非阻塞)，而其他失败的进程则捕获accept抛出的异常。
     避免惊群
    这是nginx的解决思路。具体措施有使用全局互斥锁，每个子进程在epoll_wait()之前先去申请锁，申请到则继续处理，获取不到则等待，并设置了一个负载均衡的算法（当某一个子进程的任务量达到总设置量的7/8时，则不会再尝试去申请锁）来均衡各个进程的任务量。
    这种方案的开发成本会比较高。

     现在来介绍我们的方案，该方案基于Linux kernel 3.9带来了SO_REUSEPORT特性，目的是避免惊群而非无视惊群。
   SO_REUSEPORT特性支持多个进程或者线程绑定到同一端口，提高服务器程序的性能，解决如下问题：允许多个套接字 bind()/listen() 同一个TCP/UDP端口，并且在内核层面实现负载均衡。

    下面我们来看一下相关的代码：
    在子进程中创建socket，并为每个socket增加SO_REUSEPORT属性，bind()/listen()同一个端口

//开辟多进程
for(int f=1;f<=my_config->fork_max;f++)
{
	if(fork() == 0)
	{
		//监听主端口
		int iSvrFd;   
		struct sockaddr_in sSvrAddr; 
		memset(&sSvrAddr, 0, sizeof(sSvrAddr));   
		sSvrAddr.sin_family = AF_INET;   
		sSvrAddr.sin_addr.s_addr = inet_addr("0.0.0.0");     
		sSvrAddr.sin_port = htons(my_config->socket_port);
		//创建tcpSocket
		iSvrFd =socket(AF_INET,SOCK_STREAM,0);
		//设置为非阻塞
		int flags = fcntl(iSvrFd,F_GETFL,0); 
		fcntl(iSvrFd,F_SETFL,flags | O_NONBLOCK |SO_REUSEPORT);
		//绑定监听
		bind(iSvrFd,(struct sockaddr*)&sSvrAddr,sizeof(sSvrAddr));   
		listen(iSvrFd,my_config->listen); 
		//创建线程池
		cthread_pool_manager=boost::shared_ptr(new cthread_pool(my_config));
		//将指向线程池的智能指针回传进去(必须)
		cthread_pool_manager->self_ptr=cthread_pool_manager;
		//初始化线创建程池内的线程
		cthread_pool_manager->init();
		//=================================================
		//初始化epool
		error_report("creating my_epool obj ...\n");
		boost::shared_ptr my_ep(new my_epool(my_config->epool_events_max));
		if(!my_ep->flag) error_report(my_ep->error_msg,true);
		//=================================================
		//将主端口加入epoll
		my_ep->add_fd(iSvrFd);
		//=================================================
		//监听epoll
		while(1)
		{
			//............
		}
	}
	else
	{
		continue;
	}
}

   现在我们再来看一下程序执行的效果，拿出证据证明上述操作确实避免了惊群问题：
    我们启动一个程序，该程序会创建两个子进程并同时监听9001端口。然后利用telnet向9001进行连接，其中一个子进程唤醒了epool的监听，而另一个没有。

    上面的图已经充分证明，SO_REUSEPORT可以有效地避免惊群问题。我想我们就到这里。