linux网络编程——谈半同步/半异步网络并发模型

一. 基础知识导入

所谓『网络并发模型』，亦可称之为『网络并发的设计模式』。『半同步/半异步』模式是出镜率很高的一种模式，要想解释清楚它，我要先从基础讲起。熟悉的同窗能够跳过本节。

1.1 单线程IO多路复用

首先带你们再回顾一个典型的单线程Polling API的使用过程。Polling API泛指select/poll/epoll/kqueue这种IO多路复用API。

一图胜千言：

关于套接字，相信你们都不陌生，咱们知道套接字有两种：服务端套接字（被动套接字）和客户端套接字。套接字在listen调用以后，会变成被动套接字，等待客户端的链接（connect）。其实socket的本质是一种特殊的fd（文件描述符）。

为了表达简洁清晰，用socket指代服务端套接字，fd表示链接以后的客户端套接字。

单线程Polling API的常规用法是：

让Polling API监控服务端socket的状态，而后开始死循循环，循环过程当中主要有三种逻辑分支：

服务端socket的状态变为可读，即表示有客户端发起链接，此时就调用accept创建链接，获得一个客户端fd。将其加入到Polling API的监控集合，并标记其为可读。

客户端fd的状态变为可读，则调用read/recv从fd读取数据，而后执行业务逻辑，处理完，再将其加入到Polling API的监控集合，并标记其为可写。

客户端fd的状态变为可写，则调用write/send将数据发送给客户端。

须要C/C++ Linux服务器架构师学习资料加群812855908（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享

1.2 平民级的多线程IO

最平民的多线程（or多进程）网络IO的模式，比较简单，这里就不画图了。就是主线程建立多个线程（pthread或者std::thread），而后每一个线程内部开启死循环，循环体内进行accept。当无客户端链接的时候accept是阻塞的，当有链接到时候，则会被激活，accept开始返回。这种模式在上古时代，存在accept的『惊群』问题（Thundering herd Problem），即当有某个客户端链接的时候，多个阻塞的线程会被唤醒。固然这个问题在Linux内核2.6版本就已经解决。

二. 半同步/半异步

『半同步/半异步』模式（Half-Sync/Half-Async，如下简称HSHA），所谓『半同步/半异步』主要分三层：

异步IO层+队列层+同步处理层

固然也使用了多线程，通常是一个IO线程和多个工做线程。IO线程也能够是主线程，负责异步地从客户端fd获取客户端的请求数据，而工做线程则是并发的对该数据进行处理。工做线程不关心客户端fd，不关心通讯。而IO线程不关心处理过程。

那么从IO线程到工做线程如何交换数据呢？那就是：队列。果真又应了那句老话『在软件工程中，没有一个问题是引入中间层解决不了』。

经过队列来做为数据交换的桥梁。所以能够看出，在HSHA模式中，有咱们熟悉的『生产者、消费者』模型。固然因为涉及到多线程的同时操做队列，因此加锁是必不能够少的。

潦草地画了一个图，不是UML，比较随意……

2.1 异步IO与同步处理

所谓异步：在接收客户端链接，获取请求数据，以及向队列中写入数据的时候是异步的。在写入完成可能会执行预设的回调函数，进行预处理和其余通知操做。也即是Proactor模式（与之相对的是Reactor，下文有述）。

关于异步IO，严重依赖内核的支持，好比Windows的IOCP就是公认的不错的异步IO实现，而Linux的AIO系列API虽然模拟了异步操做的接口，可是内部仍是用多线程来模拟，实则为伪异步，十分鸡肋。另外请注意epoll不是异步IO！，epoll虽然能够一次返回多个fd的就绪状态，但若要获取数据，单线程的话仍是同步一个fd一个fd的read的。

所谓同步：一个客户端链接的一次请求，其具体处理过程（业务逻辑）是同步的。虽然在消费队列的时候是多线程，但并不会多个线程并行处理一次请求。

综上，也就是说当一个客户端发送请求的时候，整个服务端的逻辑一分为二。第一部分，接收请求数据是异步的；第二部分，在收完数据以后的处理逻辑是同步的。所谓半同步，半异步所以得名。

2.2 返回数据是怎么发送的？

读完上一节，你明白了HSHA的名称由来，可是你发现没，漏讲了一部分。那就是『数据是如何发送回去的』。甚至我那个潦草的图里面都没有画。不止你有此一问，我其实也疑惑。关于HSHA，不少资料都有介绍如何用异步IO接收客户端请求数据，但却没有谈到应该如何发送响应数据给客户端。即使是HSHA的名称出处《POSA》这本书也没深究这部分。固然咱们学习要活学活用，懂得灵活变通，而不能生搬硬套。关于如何发送，其实自己不是难点，咱们也不须要拘泥于必定之规。

它的实现方式能够有不少，好比在工做线程中，处理完成以后，直接在工做线程向客户端发送数据。或者再弄一个写入队列，将返回数据和客户端信息（好比fd）放入该队列（在工做线程中侵入了IO逻辑，违背解耦初衷）。而后有一组专门负责发送的线程来取元素和发送（这种方式会增长额外的锁）。总之也不须要过度追求，什么标准、什么定义。

2.3 队列思考

队列中元素为封装了请求数据和其余元数据的结构体，能够称之为任务对象。HSHA模式不必定是多线程实现的，也能够是多进程。那么此时队列多是一个共享内存，经过信号量同步来完成队列的操做。若是是多线程实现的。那么队列能够是一个普通的数组，多线程API若使用pthread，则同步便可使用pthread_mutext_t。固然也可使用C++11的std::thread。

关于工做线程消费队列数据的方式，和通常的『队列』模型相同，便可分为『推』和『拉』两种模型。一般HSHA为推模型，即若队列尚无数据，则工做线程阻塞休眠，等待数据产生。而当IO线程写入了数据以后，则会唤醒休眠的工做线程来处理。很明显在pthread的语义下，这必然是一个条件变量（pthread_cond_t）。须要注意的是条件变量的惊群问题，便可能同时唤醒多个工做线程。前文虽然提到accept的惊群问题早被内核解决，可是条件变量的惊群问题仍在。这里须要注意的是虽然 pthread_cond_wait 自己便能阻塞线程，但通常仍是要用while而非if来作阻塞判断，一方面即是为了不惊群，另外一个方面是某些状况下，阻塞住的线程可能被虚假唤醒（即没有pthread_cond_signal就解除了阻塞）。

用伪码来描述一下：

while (1) {
    if (pthread_mutex_lock(&mtx) != 0) { // 加锁
        ... // 异常逻辑
    }
    while (!queue.empty()) {
        if (pthread_cond_wait(&cond, &mtx) != 0) {
            ... // 异常逻辑
        }
    }
    auto data = queue.pop();
    if (pthread_mutex_unlock(&mtx) != 0) { // 解锁
        ... // 异常逻辑
    }
    process(data); // 处理流程，业务逻辑
}

保险起见，上面的empty和pop函数内部通常也最好加锁保护。

再谈一下拉模型。即不须要条件变量，工做线程内作死循环，去不停的轮训队列数据。两种模型各有利弊，主要要看实际业务场景和业务规模，抛开业务谈架构，经常是狭隘的。若是是IO密集型的，好比并发度特别高，以致于几乎总能取到数据，那么就不须要推模型。

另外关于队列的数据结构，多进程须要使用到共享内存，相对麻烦，实际用多线程就OK了。前文提到多线程环境下用普通数组便可，尽管数组是定长的，当超过预设大小的时候，表示已经超过了处理能力则直接报错给客户端，即为一种『熔断』策略。咱们固然也可使用vector，可是切记，除非你真的了解容器，不然不要滥用。vector不是线程安全的，所以加锁也是必要的。另一个隐患是，vector是可变长的，不少人自觉得便本身为得起便利，除非系统内存不足，捕获一下bad_alloc，不然就觉得万事大吉。却不知vector在进行realloc，即从新分配内存的时候，以前的返回给你的迭代器会失效！

请记住C++不是银弹，STL更不是！

三. 半同步半反应堆

HSHA模式十分依赖异步IO，然而实现真异步一般是比较困难，即使Linux有AIO系列API，但其实十分鸡肋，内部用pthread模拟，在这方面不如Windows的IOCP。而当时IO多路复用技术的发展，带给了人们新的思路，用IO多路复用代替异步IO，对HSHA进行改造。这就是『半同步/半反应堆』模型（Half-Sync/Half-Reactor，如下简称HSHR）。

我又画了一个潦草的图：

循环之初，Polling API（select/poll/epoll/kqueue）只监听服务端socket，当监测到服务端socket可读，就会进行进行accept，得到客户端fd放入队列。也就是说和HSHA不一样，HSHR的队列中存放的不是请求数据，而是fd。工做线程从队列中取的不是数据，而是客户端fd。和HSHA不一样，HSHR将IO的过程侵入到了工做线程中。工做线程的逻辑循环内从队列取到fd后，对fd进行read/recv获取请求数据，而后进行处理，最后直接write/send客户端fd，将数据返回给客户端。能够看出来，这种IO的方式是一种Reactor模式，这就是该模型中，半反应堆（Half-Reactor）一词的由来。

固然队列中存储的元素并非简单的int来表示fd，而是一个结构体，里面除了包含fd之外还会包含一些其余信息，好比状态之类的。若是队列是数组，则须要有状态标记，fd是否就绪，是否已被消费等等。工做线程每次取的时候不是简单的竞争队首元素，而是也要判断一下状态。固然若是是链表形式的队列，也能够经过增删节点，来表示fd是否就绪，这样工做线程每次就只须要竞争队首了，只不过在每一个链接频繁发送数据的时候，会频繁的增删相同的fd节点，这样的链表操做效率未必比数组高效。

epoll必定比select效率高吗？

曾几什么时候，有位面试官问我“epoll必定比select效率高吗？”。我说“恩”。而后他一脸鄙夷，和我再三确认。面试结束后。我翻遍谷歌，想找出一些 what time select is better than epoll的例子来。可是很遗憾，没有发现。百度搜索国内的资料，发现国人却是写过一些。好比说在监视的fd个数很少的时候，select可能比epoll更高效。

貌似不少人对select的理解存在误区，认为只有监视的fd个数足够多的时候，因为select的线性扫描fd集合操做效率才比较低，因此就想固然的认为当监视的fd个数不是不少的时候，它的效率可能比摆弄红黑树和链表的epoll要更高。其实不是，这个扫描效率和fd集合的大小无关，而是和最大的fd的数值有关。好比你只监视一个fd，这个fd是1000，那么它也会从0到1000都扫描一遍。固然这也不排除fd比较少的时候，有更大的几率它的数值通常也比较小，可是我不想玩文字游戏，若是硬要说fd集合小的时候，epoll效率未必最优的话，那也是和poll比，而不是select。

poll没有select那种依赖fd数值大小的弊端，虽然他也是线性扫描的，可是fd集合有多少fd，他就扫描多少。毫不会多。因此在fd集合比较小的时候，poll确实会有因为epoll的可能。可是这种场景使用epoll也彻底能胜任。固然poll也并不老是因为select的。由于这两货还有一个操做就是每次select/poll的时候会将监视的fd集合从用户态拷贝到内核态。select用bitmask描述fd，而poll使用了复杂的结构体，因此当fd多的时候，每次poll须要拷贝的字节数会更多。因此poll和select的比较也是不能一律而论的。

固然我也没说select在“某些”状况下确定就不会高于epoll哦（括弧笑）。

虽然整体来讲select不如epoll，但select自己的效率也没你想象中那么低。若是你在老系统上看到select，也运行的好好的，那真的只是Old-Fashion，不存在什么很科学的解释，说这个系统为何没采用epoll。Anyway，除非你不是Linux系统，不然为何对epoll说不呢？