浅谈几种服务器端模型——多进程并发式

引言:上篇文章讲到同步阻塞迭代式的进程方式,此篇文章讲述一下关于处理单进程阻塞于系统调用的情况。使用方式是多进程的方式,可以减少很大一部分的因为进程阻塞所带来的服务器无法响应问题。

 

基本思想是这样,如上篇文章所述,单进程阻塞在read() 系统调用的时候,会导致服务器无法响应其他客服端的连接请求,那么我们可以通过在服务器fork() 出很多子进程来处理业务,而主进程负责 accept() 其他的客户连接。

主体框架是这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
while(1) {
 
  fd = accept(...);
  ret = fork() ;
  switch ( ret )
  {
       case -1 :
        err_handler();
         break ;
       case 0  :   // 子进程
        handler_fd( fd );
         break ;
       default :   // 父进程
         continue ;
  }
}

总体来说,主进程负责 accept() 连接,子进程处理连接。

当然,在handler_fd(fd) 中,可以关闭监听套接口等,只负责处理连接套接口。处理过程也是和上一章所说的一样。

1
2
3
4
5
read(fd,buf,n);
 
dosomething(buf);
 
write(fd,buf,n);

  

在父进程中需要设置信号处理函数,用来处理子进程退出时候产生的 SIG_CHLD型号,信号处理函数中调用 wait() 。避免产生僵尸进程、

比较下这个模型和前一个同步阻塞迭代式:

(1)并发量:这里的服务器主进程不再阻塞于read或者write()系统调用,而是通过子进程完成业务处理。阻塞也只是阻塞在子进程中。那么可以减轻服务器主进程的相应时间要求。并发量大大加强,但是会受到操作系统的限制。

(2)代码复杂度:越到后面的代码复杂度肯定越高,开发难度也会慢慢加强。

(3)稳定性:服务器的稳定性现在两个版本还没有体现出来。不过如果没有处理好进程之间的协作和并发控制等,第二个版本还是会比第一个版本稍微显得不稳定。

总结:多进程并发式的服务器端模型的好处就是,主进程不用阻塞在IO系统调用中,而专注于负责处理连接请求。但是,进程本身的开销是非常大的,频繁的创建进程会消耗很多的系统资源。所以,还有其他的处理方式,那就是线程模型。这就是下一篇文章要谈论的:多线程方式(会有一个线程池的实例)

你可能感兴趣的:(linux)