服务器端网络编程之线程模型

　　上一篇文章《服务器端网络编程之 IO 模型》中讲到服务器端高性能网络编程的核心在于架构，而架构的核心在于进程-线程模型的选择。本文将主要介绍传统的和目前流行的进程-线程模型，在讲进程-线程程模型以前须要先介绍一种设计模式： Reactor 模式，不明白的看这里《设计模式详解》，文中有一句话对 Reactor 模式总结的很好，引用下。

　　Reactor 模式首先是事件驱动的，有一个或多个并发输入源，有一个Service Handler，有多个Request Handlers；这个Service Handler会同步的将输入的请求（Event）多路复用的分发给相应的Request Handler。若是用图表示的以下：

​

　　不知道读者有没有发现 Reactor 模式跟 IO 模型中的 IO 多路复用模型很是类似 ，在学习网络编程过程当中也被这两个概念迷惑了好久。其实在设计模式层面 IO 多路复用也是采用 Reactor 模式的。IO 多路复用模型能够当作是 Reactor 模式在 IO 模型上的应用，而今天咱们要讲的是 Reactor 模式在进程-线程模型上的应用。

　　在个人看来，进程-线程模型能够分为非 Reactor 模式和 Reactor 模式两种（固然还有 Proactor 模式，这种本文先不讲，由于使用的比较少，并且我也还没搞懂这种模式）。非 Reactor 模式和 Reactor 模式的两种进程-线程模型下具体又分不少种，后面会一一列举。非 Reactor 模式的进程-线程模型是传统的模型，如今已经不多见，放在这里主要是让读者作个了解同时与 Reactor 模式的进程-线程模式作个对比。

非 Reactor 模式的进程-线程模型

　　传统模型不使用 IO 多路使用，因此问题比较多。初学者建议看下这部分，若是你以为被迷糊了或者不感兴趣能够跳过该部分，直接看 Reactor 模式的部分便可。但该部分的第 一、2 点须要了解下。

  一、单进程单线程：

​

　　描述：这种模型全部的逻辑都在在一个进程中，包括创建链接->Read 链接上的数据->业务处理->Write 回一些数据而后一直循环下去。该模型一次只能处理一个链接，这个在真正的应用中是没有的。初学者在模仿《Unix网络编程卷 I》例子编写网络程序时应该会使用这种模型，固然例子中通常会在 Write 后面多个 Close 链接的动做，以避免在处理下一个链接的时候形成前一个句柄泄露。

　　优势：代码简单，无需去了解进程、线程的概念，适合学习网络编程的初学者。在不了解进程-线程模型状况下的默认模型。

　　缺点：没有任何实用价值。

　　二、单进程多线程

​

　　描述：进程只作创建链接的动做，每接收一个链接就建立一个线程，在此链接上的读->业务处理->写->关闭链接都在线程中去作，能够采用线程池的方式减小线程的建立和销毁。这种线程模型有必定的应用场景，Tomcat 三种线程模型之 BIO 用的就是这种进程-线程模型。初学者在学习完单进程单线程模型后对线程有所了解便可开始学习该种模型，能够实现一个简单的聊天室程序。

　　优势：能够同时与多个 Client 创建链接，接收链接和处理链接业务分开。

　　缺点：每一个链接占用一个线程，当链接上没有数据的时候形成线程资源浪费，能够创建的链接数比较有限。

　　三、多进程单线程

​

　　描述：

　　(1) 主进程启动时建立监听套接字并监听，而后 fork 出 N 个子进程。

　　(2) 因为父子进程的继承性，子进程同时也在端口监听，而后在父进程中关闭监听。

　　(3) 父进程负责子进程的建立、销毁、资源回收等，子进程负责链接的创建->Read->业务处理->Write 等。

　　因为全部进程都在同一个端口监听，该模型会出现一个比较知名的现象---惊群现象：当有一个链接来临时，全部子进程都会被唤醒，可是最后能与 Client 创建链接的只有一个，形成资源浪费（系通调度也是消耗 CPU 的）。不过 linux 2.6 版本之后已经在内核消除了惊群，当有链接来临只会唤醒一个等待在 accept() 上的进程。即便内核没修复，在应用层也能够用锁的方式防止惊群。

　　缺点：这种模型是单进程单线程的进化版本，然而并无什么卵用。且增长了开发的难度。因此不列出它的优势，介绍这种模型主要是引出惊群的概念，在后面的 Reactor 模型中的多进程状况下也会出现相似的状况。

Reactor 模式的进程-线程模型

　　该模式通常是 Reactor 模型 + IO 多路复用，下面的任何一种模型都具备必定的实用场景。

　　一、单进程单线程：

​

　　描述：只有一个进程，监听套接字和链接套接字上的事件都由 Select 来处理，

　　(1) 若是有创建链接的请求过来，Acceptor 负责接受并与之创建链接，同时将链接套接字加入 Select 进行监听；

　　(2) 若是某个链接上有读事件则进行 Read->业务处理->Write 等操做；

　　(3) 如此循环反复。

　　优势：编程简单，对于业务处理不复杂的后台，基本能知足服务器端网络编程。老东家的服务器端程序全是这种模式，主要缘由有以下缘由

　　(1) 若是一台机器性能不行，那就向集群中新增一台。

　　(2) 业务处理并不复杂。

　　(3) 扩展成多进程的话，若是不是多核意义不大。

　　(4) 若是采用单进程多线程，C++ 处理线程不像 Java 简单，还要考虑并发的问题，收益比不大。

　　缺点：会有阻塞，在进行业务处理的时候不能进行其余操做：如创建链接，读取其余套接字上的数据等。

　　二、单进程多线程：

​

　　描述：与单进程单线程相似，不一样的是该模型将业务处理放在线程中，进程就不会阻塞在业务处理上。

　　优势：比较完美的进程-线程模型，在 Java 实现中复杂度也不高。不少网络库都是基于此，好比 Netty 。

　　缺点：待补充。

　　三、多进程单线程：

​

　　描述：与非 Reactor 模式中的多进程单线程类似，只是本模式在子进程中使用了 IO 多路复用，实用性如下就上来了。大名鼎鼎的 nginx 就采用这种进程-线程模型

　　优势：编程相对简单，充分利用多核。能知足高并发，否则 nginx 也不可能采用这种模式。

　　缺点：子进程仍是会阻塞在业务处理上。

　　四、多进程多线程

　　描述：这里再也不画出图形，就是在在子进程上将业务处理交给多线程处理，参考单进程多线程里的线程池那里。

　　优势：充分利用多核同时子进程不会阻塞在业务处理上

　　缺点：编程复杂。

　　五、主从进程 +多线程：

​

　　描述：前面几种 Reactor 模式的进程-线程模型中，链接的创建和链接的读写都是在同一进程中。本模型中将链接的创建和链接读写放在不一样的进程中。

　　(1) 主进程在监听套接字上 Select 阻塞，一旦有请求过来则与之创建链接，并将链接套接字传递给从进程。

　　(2) 从进程在链接套接字上 Select 阻塞，一旦链接上有数据过来则进行 Read，并将业务处理经过线程来处理。若是有必要还会向链接 Write 数据。

　　优势：链接的创建和链接的读写分开在不一样进程中，处理效率会更高。该模型比单进程多线程模式还更优一点，且也能够利用多核。

　　缺点：编程复杂。

　　以上就是常见的进程-线程模型，使用了 IO 多路复用的线程模型通常均可以称为 Reactor 模型，因此不用纠结 IO 多路复用与 Reactor 模式之间的关系。由 C++ 转 Java 后，虽然再也不从事网咯编程。可是在看完《Netty 权威指南》后又想结合以前的工做经验讲讲一个网络库设计须要考虑的一些要素，同时作一些 Netty 的分享。在后续的文章中会出，敬请期待！记得关注下哦~