编写网络服务程序的常用编程模型

今天大概总结一下编写服务端程序常用的编程模型。参考UNP第三版第三十章和陈硕的muduo那本书，强烈建议仔细阅读。注意以下代码只是为了显式框架或者说编程模型，不是完整的程序，深夜写的比较任性，不要见怪。

accept + read/write

这个不是并发服务器，而是迭代服务器（iterative server）。 它一次服务一个客户。不适合长连接，适合 daytime 这种 write-only 短连接服务。

 void handle(client_socket, client_address)
{
while(true)
{
data = client_socket.recv(4096);
if(data)
client_socket.send(data);
else
do_error();
}
}
while(true){
connfd = server_socket.accept();
handle(client_socket, client_address);
}

accept + fork

这种模型也叫 process-per-connection，编写出的是多进程并发服务器程序，为每个客户调用 fork 派生一个子进程，使得服务器能够同时服务多个客户。这是传统的 Unix 并发网络编程方案，适合并发连接数不大的情况，适合“计算响应的工作量远大于 fork() 的开销” 这种情况，每个客户现场 fork 一个子进程比较耗费 CPU 时间，这样连接数目的限制是能够开多少个线程。

while(true){
connfd = accept(listenfd, clientaddr, &clientlen);
if((childpid = fork()) == 0){ // child process
close(listenfd);
handle_client(connfd);
exit(0);
}
close(connfd);
}

accept + thread

这种模型也叫 thread-per-connection，是把上面的进程换成了线程，即为每个客户请求创建一个线程，是一个多线程模型，这样开销就相对进程来说小了不少，这样现场为每个客户创建一个线程比为每个客户现场派生一个进程快很多，而且一般这样比预先派生子进程还要快。

while(true)     // 主线程循环阻塞在 accept调用
{
connfd = accept(listenfd, clientaddr, &clientlen);  // 当返回一个连接时
pthread_create(&tid, NULL, &doit, (void *)connfd);  //就创建一个新线程，将connfd传递给线程
}

void* doit(void *arg)
{
……
handle_client((int)arg);
close((int)arg);
……
}

pre fork

这种方案不像传统的并发服务器那样为每个客户现场派生一个进程，而是在启动阶段预先派生一定数量的子进程，当多个客户连接到达时，这些子进程立即就能为它们服务。预先创建完进程之后，之后可以有几种不同的处理，比如每个子进程调用 accept（无锁保护）、以文件上锁方式保护 accept、以线程互斥锁上锁方式保护 accept、由父进程向子进程传递套接字描述符。

显而易见优点是省去了现场 fork 子进程的开销，缺点是要猜测预先派生多少子进程，这一点可以通过手段来应对，父进程持续监视可用/闲置子进程数，一旦该值降低到某个阀值就派生额外的子进程；同样一旦该值超过另一个阀值就终止一些过剩的子进程。

看第一种：子进程调用accept，无上锁保护

static pid_t   *pids;               // 存放各个子进程ID的数组
pids = alloc_mem(childnumbers, sizeof(pid_t));      // 申请空间

for(i=0; i<childnumbers; i++)
pids[i] = child_make(i, listenfd, addrlen);     //  创建各个子进程

pid_t child_make(int i, int listenfd, int addrlen)
{
pid_t pid;
if( (pid=fork()) > 0)   // 父进程
return pid;     
child_main(i, listenfd, addrlen);   // 在这个里面循环调用 accept ，然后处理客户请求，最后关闭连接
}
void child_main(i, listenfd, addrlen)
{
while(1)
{
connfd = accept(listenfd, clientaddr, &clientlen);  // 接受连接
handle_client(connfd);  // 处理
close(fd);  // 关闭
}
}

像这种方式会出现“惊群”现象，怎么说？服务器进程在程序启动阶段派生N个子进程，它们各自调用 accept 并因而均被投入睡眠，当第一个客户连接到达时，所有N个子进程均被唤醒（因为所有子进程所用的监听描述符指向同一个socket结构，都睡在这个 socket 结构的等待队列上），只有最先运行的子进程获得那个客户连接，其余继续睡眠。这样就会导致性能受损，测量性能受多少影响就超出了本文要讲的东西了（我也不会……）。

那么如何解决呢？让应用进程在调用accept前后安置某种形式的锁，这样任意时刻只有一个子进程阻塞在 accept 调用中，其他子进程则阻塞在试图获取用于保护 accept 的锁上。 这就是上面提到的 以文件上锁方式保护 accept、以线程互斥锁上锁方式保护 accept，代码这里不贴了。

还有一个修改版本是只让父进程调用 accept，然后把所接受的已连接套接字“传递”给某个进程，这样做绕过了为所有子进程的 accept 调用提供上锁保护的可能需求。这个代码实现更复杂，要会用进程间通信，父进程还要跟踪子进程的忙闲状态，以便给空闲进程传递新的套接字。

pre threaded

预先创建一个线程池，并让每个线程各自调用 accept，取代让每个线程都阻塞在 accept 调用，我们用互斥锁以保证任何时刻只有一个线程在调用 accept。

thread_make();  // 首先创建指定数量的线程

void* thread_func(void *arg)
{
while(1){
pthread_mutex_lock(&mutex);
connfd = accept(listenfd, clientaddr, &clientlen);
pthread_mutex_unlock(&mutex);
handle_client(connfd);
close(connfd);
}
}

还有一个修改版本是主线程统一 accept，并把各个客户连接传递给池中某个可用线程。问题在于主线程如何把一个已连接的套接字传递给线程池中某个可用线程，有很多方式。

细分开来上面一共提到9个不同的服务器程序设计模型，它们都是阻塞式网络编程，程序流程通常阻塞在 read() 上，等待数据到达。但是 TCP 是全双工协议，同时支持 read() 和 write() 操作，当进程/线程阻塞在 read() 上，但程序又想给这个 TCP 连接发送数据该怎么办？比如 echo client、proxy。

一种方法是用两个进程/线程，一个负责读，一个负责写。另一种方式是使用 IO multiplexing，也就是 select/poll/epoll/kqueue 这一系列多路复用手段，让一个程序流程能处理多个连接。IO复用其实复用的不是IO连接，而是复用IO线程，讲到这里就要引出 Reactor 模式了，它的主要意义是将消息（IO事件）分发到用户提供的处理函数，并保持网络部分的通用代码不变，独立于用户的业务逻辑，没听过的请自行查询。

poll(reactor)

这是单线程的 reactor 方案，在没有事件的时候，线程等待在select/poll/epoll_wait 等函数上，事件到达后开始 read->decode->compute->encode->write。只有一个线程事件是顺序处理的，一个线程同时只能做一件事情，如果要执行延迟计算（把compute过程推迟100ms），那么应该注册超时回调，不能调用sleep()之类的阻塞调用，以避免阻塞当前 IO线程（Reactor事件循环所在的线程通常叫IO线程）。

while(true){
    n = epoll_wait(epfd, events, maxevents, -1);
    for(i=0; i<n; i++){
        if(events[i] == listenfd)
            // 处理连接
        else if (events[i].events & EPOLLIN)
        {
            // read compute write
            // 修改标识符
        }
        else
            // 其他处理
    }
}

reactor + thread-per-task

这是一个过渡方案，收到客户请求后，不在 IO 线程计算，而是创建一个新的线程去计算，以充分利用多核。需要注意它为每个请求（而不是每个连接）创建了一个新线程，这个开销可以用线程池来避免，后面会说到。还有一个问题是 out-of-order，即同时去创建多个线程去计算同一个连接上收到的多个请求，那么算出接锅的次序是不确定的，可能第二个请求计算时间更短，比第一个先返回。

reactor + worker thread

为了让返回结果的顺序确定，我们可以为每个连接创建一个计算线程，每个连接上的请求固定发给同一个线程去计算，先到先得。这样的话并发连接数受限于线程数目，

reactor + thread pool

这个方案是弥补方案7中为每个请求创建线程的缺陷，使用固定大小的线程池。全部的IO工作都在一个Reactor线程完成，而计算任务交给 thread poll。同样有乱序的可能。
线程池的另外一个作用是执行阻塞操作，让线程池来调用阻塞的IO函数等阻塞操作，可以避免阻塞IO线程，不会影响其他的客户连接。

reactors in threads

muduo、netty 内置的多线程方案，特点是 one loop per thread。有多个Reactor线程，muduo 采用的是固定大小的 Reactor pool，有一个 main Reactor 负责 accept 连接，然后把连接挂在某个 sub Reactor 中。这样该连接的所有操作都在那个 sub Reactor 所处的线程中完成，因此请求的顺序性有保证；多个连接可能被分到多个线程，以充分利用CPU。

reactors in processes

这是 Nginx 的内置方案，如果连接之间无交互，这种方案是很好的选择。工作进程之间相互独立，可以热升级（第一次听说……）。

reactors + thread pool

把方案9和方案10混合，既使用多个 Reactor 来处理 IO，又使用线程池来处理计算。这种方案适合既有突发IO（利用多线程处理多个连接上的IO），又有突发计算（利用线程池把一个连接上的计算任务分到多个线程去做）的应用。