架构师的视角当然需要特别关注高性能架构的设计,而高性能架构设计主要集中在两方面:
除了以上两点,最终系统能否实现高性能,还和具体的实现及编码相关 。但架构设计是高性能的基础,如果架构设计没有做到高性能,则后面的具体实现和编码能提升的空间是有限的 。形象地说,架构设计决定了系统性能的上限,实现细节决定了系统性能的下限
单服务器高性能的关键之一就是服务器采用的网络编程模式,网络编程模式的设计有两个关键点:
而这两点最终都和操作系统的I/O模型及进程模型相关:
PPC 是 Process per Connection 的缩写 ,其含义是指每次有新的连接就新建一个进程去专 门 处理这个连接的请求 ,这是传统的 UNIX 网络服务器所采用的模型,其基本的流程是这样的:
- 父进程接受链接,然后fork子进程
- 子进程处理链接相关请求,然后子进程关闭连接
- 父进程fork子进程后,调用了close,实际上并不是关闭连接,而是将连接的文件描述符引用计数减一,真正的关闭连接时等子进程也调用了close之后,链接对应的文件描述符引用计数变为0后,操作系统才会真正的关闭连接
PPC 模式实现简单,比较适合服务器的连接数没那么多的情况。例如,数据库服务器。对 于普通的业务服务器,在互联网兴起之前,由于服务器的访问量和并发量并没有那么大,这种 模式其实运作得也挺好 。而互联网 兴起后,服务器的并发和访 问 量从几十剧增到成千上万,这 种模式的弊端就凸显出来了,主要体现在如下几个方面:
针对 PPC 模式不同的缺点,产生了不同的解决方案 ,在 PPC 模式中,当连接进来时才“ fork ” 新进程来处理连接请求,由于“ fork "进程代价高,用户访问时可能感觉比较慢, prefork 模式的出现就是为了解决这个问题,prefork 就是提前创建进程(pre- fork) 系统在启动的时候就预先创建好进程, 然后才开始接受用户的请求,当有新的连接进来的时候,就可以省去“ fork ”进程的操作,让用户的访问更快、体验更好, prefork 的基本示意图:
TPC是Thread per Connection的缩写 ,其含义是指每次有新的连接就新建一个线程去专门处理这个连接的请求。与进程相比,线程更轻量级,创建线程的消耗比进程要少得多;同时多线程是共享进程内存空间的, 线程通信相比进程通信更简单。 因此,TPC 实际上是解决或弱化了PPC的fork代价高的问题和父子进程通信复杂的问题
TPC 的基本流程如下 :
- 父进程接受连接(图中accept)
- 父进程创建子线程(图中 pthread)
- 子线程处理连接的读写请求(图中子线程read 、业务处理、write)
- 子线程关闭连接(图中子线程中的close)
不难发现,和PPC相比,主进程不用close链接了,原因在于子线程是共享主进程的进程空间的,连接的文件描述符并没有被复制,因此只需要一次close即可
TPC 虽然解决了 fork 代价高和进程通信复杂 的问题,但是也引入了新的问题:
PPC方案最主要的问题就是每个连接都要创建进程,连接结束后进程就销毁了,这样做其实是很大的浪费,为了解决这个问题,一个自然而然的想法就是资源复用,即不再单独为每个连接创建进程,而是创建一个进程池,将连接分配给进程,一个进程可以处理多个连接的业务
- 引入资源池的处理方式后,会引出 一个新的问题:进程如何才能高效地处理多个连接的业务?当一个连接一个进程时,进程可以采用“ read->业务处理-> write ”的处理流程,如果当前连接没有数据可以读,则进程就阻塞在read操作上,这种阻塞的方式在一个连接一个进程的场景下没有问题,但如果一个进程处理多个连接,进程阻塞在某个连接的read操作上,此时即使其他连接有数据可读,进程也无法去处理,很显然这样是无法做到高性能的
- 解决这个问题的最简单的方式是将read 操作改为非阻塞,然后进程不断地轮询多个连接。这种方式能够解决阻塞的问题,但解决的方式并不优雅。首先轮询是要消耗CPU的;其次如果一个进程处理几千上万的连接,则轮询的效率是很低的
为了能够更好地解决上述问题,一种自然而然的想法就是只有当连接上有数据的时候进程才去处理,这就是 I/O多路复用技术的来源,I/O多路复用这个术语在通信行业比较常见。例如,时分复用(GSM)、码分复用(CDMA)、 频分复用(GSM)等,其含义是“在一个信道上传输多路信号或数据流的过程和技术”,但如果拿这个含义套到计算机领域中就会导致混淆,因为单纯从表面含义来看,通信领域的“信道” 和计算机领域的“连接”是类似的,通信领域的“数据流”和计算机领域的“数据”是类似的。 如果直接照搬通信领域的多路复用定义到计算机领域,就会将多路复用理解为“一条连接上传输多种数据飞这与事实上的 I/O 多路复用含义相差太大。计算机网络领域的 I/O 多路复用,其中的“多路”,就是指多条连接,“复用”指的是多条连接复用同一个阻塞对象,这个阻塞对象和具体的实现有关。以 Linux 为例,如果使用select ,则这个公共的阻塞到象就是select用到的fd_set ,如果使用 epoll ,就是 epoll_create创建的文件描述符
I/O 多路复用技术归纳起来有如下两个关键实现点:
I/O 多路复用结合线程池,完美地解决了 PPC 和 TPC 模型的问题,而且“大神们”给它取了一个很牛的名字:Reactor,中文是“反应堆”,实际上这里的“反应”是“ 事件反应” 的意思,可以通俗地理解为“来了一个事件我就有相应的反应”。 Reactor 模式也叫Dispatcher模式(很多开源的系统里面会看到这个名称的类,其实就是实现 Reactor模式的),更加贴近模式本身的含义,即I/O多路复用统一监昕事件,收到事件后分配(Dispatch)给某个进程
Reactor模式的核心组成部分包括Reactor和处理资源池(进程池或线程池),其中Reactor负责监听和分配事件,处理资源池负责处理事件,初看Reactor的实现是比较简单的,但实际上结合不同的业务场景,Reactor 模式的具体实现方案灵活多变,主要体现在如下两点:
将以上两个因素排列组合一下,理论上可以有4种选择,但由于“多 Reactor 单进程”实现方案相比“单Reactor单进程”方案, 既复杂又没有性能优势,因此“ 多 Reactor 单进程”方案 仅仅是一个理论上的方案 , 实际没有应用,最终 Reactor 模式有如下三种典型的实现方案 :
以上方案具体选择进程还是线程, 更多的是和编程语言及平台相关。 例如, Java 语言一般使用线程(例如, Netty), C语言使用进程和线程都可以(例如, Nginx 使用进程 , Memcache 使用线程) 。
单 Reactor 单进程/线程的方案示意图如下(以进程为例)
select、accept、read、send是标准的网络编程API,dispatch和“业务处理”是徐娅哦完成的操作
方案详细说明如下:
单Reactor单进程的模式优点就是很简单,没有进程间通信,没有进程竞争,全部都在同一个进程内完成 。 但其缺点也是非常明显,具体表现如下:
因此,单 Reac tor 单进程的方案在实践中应用场景不多,只适用于业务处理非常快速的场景, 目前比较著名的开源软件中使用单 Reactor 单进程的是 Redis 。
C语言编写系统的一般使用单Reactor单进程,因为没有必要在进程中再创建线程; 而Java语言编写的一般使用单Reactor单线程,因为Java虚拟机是一个进程,虚拟机中有很多线程,业务线程只是其中的一个线程而已
为了避免单 Reactor 单进程/线程方案 的缺点,引入多进程/多线程是显而易见的,这就产生了第二个方案 : 单Reactor多钱程
单Reactor多线程方案示意图如下:
方案详细说明如下:
单 Reactor 多线程方案能够充分利用 多核多 CPU 的处理能力,但同时也存在如下问题:
这里说了“单 Reactor 多线程” 方案,而没说“单 Reactor多进程 ” 方案,主要原因在于如果采用多进程,子进程完成业 务处理后,将结果返回给父进程,并通知父进程发送给哪个client , 则是很麻烦的事情, 因为父进程只是通过Reactor监听各个连接上的事件然后进行分配,子进程与父进程通信时并不是一个连接。如果要将父进程和子进程之间的通信模拟为一个连接,并加入Reactor进行监听,则是比较复杂的 。而采用多线程时,因为多线程是共享数据的,因此线程间通信是非常方便的,虽然要额外考虑线程间共享数据时的同步问题,但这个复杂度比上述进程间通信的复杂度要低很多
为了解决单 Reactor 多线程的问题,最直观的方法就是将单 Reactor 改为多 Reactor ,这就产生了第三个方案 : 多 Reactor 多进程/线程。
多 Reactor 多进程/线程方案示意图如下(以进程为例)
方案详细说明如下:
多Reactor多进程/线程的方案看起来比单Reactor多线程要复杂,但实际实现时反而更加简 单,主要原因如下:
目前采用多Reactor多进程实现的著名的开源系统是Nginx,采用多Reactor多线程实现有Memcache和Netty
Nginx 采用的是多Reactor多进程的模式,但方案与标准的多Reactor多进程有差异 。具体差异表现为主进程中仅仅创建了监听端口,并没有创建mainReactor来“ accept ”连接,而是由子进程的Reactor来“ accept ”连接,通过锁来控制一次只有一个子进程进行“accept ”,子进程“accept ”新连接后就放到自己的Reactor进行处理,不会再分配给其他子进程
Reactor是非阻塞同步网络模型 ,因为真正的read和send操作都需要用户进程同步操作。这里的“同步”指用户进程在执行read和send这类I/O操作的时候是同步的,如果把 I/O 操作改为异步就能够进一步提升性能 , 这就是异步网络模型 Proactor
Proactor中文翻译为“前摄器”比较难理解,与其类似的单词是proactive, 含义为“主动的”,因此我们照猫画虎翻译为“主动器”反而更好理解。 Reactor可以理解为“来了事件我通知你, 你来处理”,而 Proactor可以理解为“来了事件我来处理,处理完了我通知你”。这里的“我” 就是操作系统内核,“ 事件”就是有新连接、有数据可读 、有数据可写这些I/O事件
方案详细说明如下:
- Proactor Initiator 负责创建Proactor和Handler,并将Proactor和Handler都通过Asynchronous Operation Processor 注册到内核
- Asynchronous Operation Processor负责处理注册请求,并完成I/O操作
- Asynchronous Operation Processor完成I/O操作后通知Proactor
- Proactor根据不同的事件类型回调不同的 Handler 进行业务处理
- Handler完成业务处理, Handler也可以注册新的Handler到内核进程
理论上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)模拟出来的异步模型