共计 5113 个字符，预计需要花费 13 分钟才能阅读完成。
一. 基础知识导入
所谓『网络并发模型』，亦可称之为『网络并发的设计模式』。『半同步 / 半异步』模式是出镜率很高的一种模式，要想解释分明它，我要先从根底讲起。相熟的同学能够跳过本节。
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 说不呢？
