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

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

 

基本思想是这样，如上篇文章所述，单进程阻塞在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;

      case0  :   // 子进程

       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系统调用中，而专注于负责处理连接请求。但是，进程本身的开销是非常大的，频繁的创建进程会消耗很多的系统资源。所以，还有其他的处理方式，那就是线程模型。这就是下一篇文章要谈论的：多线程方式（会有一个线程池的实例）