专栏上一期我介绍了单服务器高性能的PPC和TPC模式,它们的优点是实现简单,缺点是都无法支撑高并发的场景,尤其是互联网发展到现在,各种海量用户业务的出现,PPC和TPC完全无能为力。今天我将介绍可以应对高并发场景的单服务器高性能架构模式:Reactor和Proactor。
PPC模式最主要的问题就是每个连接都要创建进程(为了描述简洁,这里只以PPC和进程为例,实际上换成TPC和线程,原理是一样的),连接结束后进程就销毁了,这样做其实是很大的浪费。为了解决这个问题,一个自然而然的想法就是资源复用,即不再单独为每个连接创建进程,而是创建一个进程池,将连接分配给进程,一个进程可以处理多个连接的业务。
引入资源池的处理方式后,会引出一个新的问题:进程如何才能高效地处理多个连接的业务?当一个连接一个进程时,进程可以采用“read -> 业务处理 -> write”的处理流程,如果当前连接没有数据可以读,则进程就阻塞在read操作上。这种阻塞的方式在一个连接一个进程的场景下没有问题,但如果一个进程处理多个连接,进程阻塞在某个连接的read操作上,此时即使其他连接有数据可读,进程也无法去处理,很显然这样是无法做到高性能的。
解决这个问题的最简单的方式是将read操作改为非阻塞,然后进程不断地轮询多个连接。这种方式能够解决阻塞的问题,但解决的方式并不优雅。首先,轮询是要消耗CPU的;其次,如果一个进程处理几千上万的连接,则轮询的效率是很低的。
为了能够更好地解决上述问题,很容易可以想到,只有当连接上有数据的时候进程才去处理,这就是I/O多路复用技术的来源。
I/O多路复用技术归纳起来有两个关键实现点:
I/O多路复用结合线程池,完美地解决了PPC和TPC的问题,而且“大神们”给它取了一个很牛的名字:Reactor,中文是“反应堆”。联想到“核反应堆”,听起来就很吓人,实际上这里的“反应”不是聚变、裂变反应的意思,而是“事件反应”的意思,可以通俗地理解为“来了一个事件我就有相应的反应”,这里的“我”就是Reactor,具体的反应就是我们写的代码,Reactor会根据事件类型来调用相应的代码进行处理。Reactor模式也叫Dispatcher模式(在很多开源的系统里面会看到这个名称的类,其实就是实现Reactor模式的),更加贴近模式本身的含义,即I/O多路复用统一监听事件,收到事件后分配(Dispatch)给某个进程。
Reactor模式的核心组成部分包括Reactor和处理资源池(进程池或线程池),其中Reactor负责监听和分配事件,处理资源池负责处理事件。初看Reactor的实现是比较简单的,但实际上结合不同的业务场景,Reactor模式的具体实现方案灵活多变,主要体现在:
将上面两个因素排列组合一下,理论上可以有4种选择,但由于“多Reactor单进程”实现方案相比“单Reactor单进程”方案,既复杂又没有性能优势,因此“多Reactor单进程”方案仅仅是一个理论上的方案,实际没有应用。
最终Reactor模式有这三种典型的实现方案:
以上方案具体选择进程还是线程,更多地是和编程语言及平台相关。例如,Java语言一般使用线程(例如,Netty),C语言使用进程和线程都可以。例如,Nginx使用进程,Memcache使用线程。
1.单Reactor单进程/线程
单Reactor单进程/线程的方案示意图如下(以进程为例):
注意,select、accept、read、send是标准的网络编程API,dispatch和“业务处理”是需要完成的操作,其他方案示意图类似。
详细说明一下这个方案:
单Reactor单进程的模式优点就是很简单,没有进程间通信,没有进程竞争,全部都在同一个进程内完成。但其缺点也是非常明显,具体表现有:
因此,单Reactor单进程的方案在实践中应用场景不多,只适用于业务处理非常快速的场景,目前比较著名的开源软件中使用单Reactor单进程的是Redis。
需要注意的是,C语言编写系统的一般使用单Reactor单进程,因为没有必要在进程中再创建线程;而Java语言编写的一般使用单Reactor单线程,因为Java虚拟机是一个进程,虚拟机中有很多线程,业务线程只是其中的一个线程而已。
2.单Reactor多线程
为了克服单Reactor单进程/线程方案的缺点,引入多进程/多线程是显而易见的,这就产生了第2个方案:单Reactor多线程。
单Reactor多线程方案示意图是:
我来介绍一下这个方案:
单Reator多线程方案能够充分利用多核多CPU的处理能力,但同时也存在下面的问题:
你可能会发现,我只列出了“单Reactor多线程”方案,没有列出“单Reactor多进程”方案,这是什么原因呢?主要原因在于如果采用多进程,子进程完成业务处理后,将结果返回给父进程,并通知父进程发送给哪个client,这是很麻烦的事情。因为父进程只是通过Reactor监听各个连接上的事件然后进行分配,子进程与父进程通信时并不是一个连接。如果要将父进程和子进程之间的通信模拟为一个连接,并加入Reactor进行监听,则是比较复杂的。而采用多线程时,因为多线程是共享数据的,因此线程间通信是非常方便的。虽然要额外考虑线程间共享数据时的同步问题,但这个复杂度比进程间通信的复杂度要低很多。
3.多Reactor多进程/线程
为了解决单Reactor多线程的问题,最直观的方法就是将单Reactor改为多Reactor,这就产生了第3个方案:多Reactor多进程/线程。
多Reactor多进程/线程方案示意图是(以进程为例):
方案详细说明如下:
多Reactor多进程/线程的方案看起来比单Reactor多线程要复杂,但实际实现时反而更加简单,主要原因是:
目前著名的开源系统Nginx采用的是多Reactor多进程,采用多Reactor多线程的实现有Memcache和Netty。
我多说一句,Nginx采用的是多Reactor多进程的模式,但方案与标准的多Reactor多进程有差异。具体差异表现为主进程中仅仅创建了监听端口,并没有创建mainReactor来“accept”连接,而是由子进程的Reactor来“accept”连接,通过锁来控制一次只有一个子进程进行“accept”,子进程“accept”新连接后就放到自己的Reactor进行处理,不会再分配给其他子进程,更多细节请查阅相关资料或阅读Nginx源码。
Reactor是非阻塞同步网络模型,因为真正的read和send操作都需要用户进程同步操作。这里的“同步”指用户进程在执行read和send这类I/O操作的时候是同步的,如果把I/O操作改为异步就能够进一步提升性能,这就是异步网络模型Proactor。
Proactor中文翻译为“前摄器”比较难理解,与其类似的单词是proactive,含义为“主动的”,因此我们照猫画虎翻译为“主动器”反而更好理解。Reactor可以理解为“来了事件我通知你,你来处理”,而Proactor可以理解为“来了事件我来处理,处理完了我通知你”。这里的“我”就是操作系统内核,“事件”就是有新连接、有数据可读、有数据可写的这些I/O事件,“你”就是我们的程序代码。
Proactor模型示意图是:
详细介绍一下Proactor方案:
理论上Proactor比Reactor效率要高一些,异步I/O能够充分利用DMA特性,让I/O操作与计算重叠,但要实现真正的异步I/O,操作系统需要做大量的工作。目前Windows下通过IOCP实现了真正的异步I/O,而在Linux系统下的AIO并不完善,因此在Linux下实现高并发网络编程时都是以Reactor模式为主。所以即使Boost.Asio号称实现了Proactor模型,其实它在Windows下采用IOCP,而在Linux下是用Reactor模式(采用epoll)模拟出来的异步模型。
今天我为你讲了单服务器支持高并发的高性能架构模式Reactor和Proactor,希望对你有所帮助。
这就是今天的全部内容,留一道思考题给你吧,针对“前浪微博”消息队列架构的案例,你觉得采用何种并发模式是比较合适的,为什么?
© 2019 - 2023 Liangliang Lee. Powered by gin and hexo-theme-book.