一. 基础知识导入

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

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说不呢？