一. 基础知识导入
所谓『网络并发模型』,亦可称之为『网络并发的设计模式』。『半同步/半异步』模式是出镜率很高的一种模式,要想解释清楚它,我要先从基础讲起。熟悉的同学可以跳过本节。
1.1 单线程IO多路复用
首先带大家再回顾一个典型的单线程Polling API的使用过程。Polling API泛指select/poll/epoll/kqueue这种IO多路复用API。
一图胜千言:
![de7822bebde942b2c6eb866b72187df8.png](https://i-blog.csdnimg.cn/blog_migrate/8208366ccc816cf211b6212bfebe9edc.jpeg)
关于套接字,相信大家都不陌生,我们知道套接字有两种:服务端套接字(被动套接字)和客户端套接字。套接字在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服务器架构师学习资料私信“资料”(资料包括C/C++,Linux,golang技术,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK,ffmpeg等),免费分享
![0eecdcc1a02ffba58154d2d67cce4c2a.png](https://i-blog.csdnimg.cn/blog_migrate/943117f9821bbd83d03e526b2df099a9.jpeg)
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模式中,有我们熟悉的『生产者、消费者』模型。当然由于涉及到多线程的同时操作队列,所以加锁是必不可以少的。
![eaae5bb44ed8f605c12f340221b667e6.png](https://i-blog.csdnimg.cn/blog_migrate/8c4f22508065f484eb8a1b67c2cf9aeb.jpeg)
潦草地画了一个图,不是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)。
我又画了一个潦草的图:
![e6bd2876b5faf7eac4021f374e6a1a24.png](https://i-blog.csdnimg.cn/blog_migrate/0ba9bcf17ebfacb9885f327e7ee069ab.jpeg)
循环之初,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说不呢?