网络/Network - 网络编程 - 高性能 - 单服务器高性能模式[网络模型]及性能对比 - 学习/实践

1.应用场景

主要用于学习单服务器高性能模式及性能对比，尤其是网络模型，这个很重要，并将这些知识在工作中验证，实践，理解，掌握。

2.学习/操作

1.文档阅读  推荐 18 | 单服务器高性能模式：PPC与TPC-极客时间 19 | 单服务器高性能模式：Reactor与Proactor-极客时间 高性能网络编程中的线程模型看完这篇就会了！ - 知乎 -- 作为补充 加餐｜单服务器高性能模式性能对比-极客时间 2.整理输出 原文 18 | 单服务器高性能模式：PPC与TPC 高性能是每个程序员的追求，无论我们是做一个系统还是写一行代码，都希望能够达到高性能的效果，而高性能又是最复杂的一环，操作系统、CPU、内存、磁盘、缓存、网络、编程语言、架构等，每个都有可能影响系统达到高性能。 一行不恰当的debug日志，就可能将服务器的性能从TPS 30000降低到8000； 一个tcp_nodelay参数，就可能将响应时间从2毫秒延长到40毫秒。 因此，要做到高性能计算是一件很复杂很有挑战的事情，软件系统开发过程中的不同阶段都关系着高性能最终是否能够实现。 站在架构师的角度，当然需要特别关注高性能架构的设计。高性能架构设计主要集中在两方面： 尽量提升单服务器的性能，将单服务器的性能发挥到极致。 如果单服务器无法支撑性能，设计服务器集群方案。 除了以上两点，最终系统能否实现高性能，还和具体的实现及编码相关。 但架构设计是高性能的基础，如果架构设计没有做到高性能，则后面的具体实现和编码能提升的空间是有限的。形象地说，架构设计决定了系统性能的上限，实现细节决定了系统性能的下限。 单服务器高性能的关键之一就是服务器采取的并发模型，并发模型有如下两个关键设计点： 服务器如何管理连接。 服务器如何处理请求。 以上两个设计点最终都和操作系统的I/O模型 & 进程模型相关。 I/O模型：阻塞、非阻塞、同步、异步。 进程模型：单进程、多进程、多线程。 在下面详细介绍并发模型时会用到上面这些基础的知识点，所以我建议你先检测一下对这些基础知识的掌握情况，更多内容你可以参考《UNIX网络编程》三卷本。 今天，我们先来看看单服务器高性能模式：PPC与TPC。 PPC PPC是Process Per Connection的缩写，其含义是指每次有新的连接就新建一个进程去专门处理这个连接的请求，这是传统的UNIX网络服务器所采用的模型。 基本的流程图是： 父进程接受连接（图中accept）。 父进程“fork”子进程（图中fork）。 子进程处理连接的读写请求（图中子进程read、业务处理、write）。 子进程关闭连接（图中子进程中的close）。 注意，图中有一个小细节，父进程“fork”子进程后，直接调用了close，看起来好像是关闭了连接，其实只是将连接的文件描述符引用计数减一，真正的关闭连接是等子进程也调用close后，连接对应的文件描述符引用计数变为0后，操作系统才会真正关闭连接，更多细节请参考《UNIX网络编程：卷一》。 PPC模式实现简单，比较适合服务器的连接数没那么多的情况，例如数据库服务器。 对于普通的业务服务器，在互联网兴起之前，由于服务器的访问量和并发量并没有那么大，这种模式其实运作得也挺好，世界上第一个web服务器CERN httpd就采用了这种模式（具体你可以参考https://en.wikipedia.org/wiki/CERN_httpd）。 互联网兴起后，服务器的并发和访问量从几十剧增到成千上万，这种模式的弊端就凸显出来了，主要体现在这几个方面： fork代价高：站在操作系统的角度，创建一个进程的代价是很高的，需要分配很多内核资源，需要将内存映像从父进程复制到子进程。即使现在的操作系统在复制内存映像时用到了Copy on Write（写时复制）技术，总体来说创建进程的代价还是很大的。 父子进程通信复杂：父进程“fork”子进程时，文件描述符可以通过内存映像复制从父进程传到子进程，但“fork”完成后，父子进程通信就比较麻烦了，需要采用IPC（Interprocess Communication）之类的进程通信方案。例如，子进程需要在close之前告诉父进程自己处理了多少个请求以支撑父进程进行全局的统计，那么子进程和父进程必须采用IPC方案来传递信息。 支持的并发连接数量有限：如果每个连接存活时间比较长，而且新的连接又源源不断的进来，则进程数量会越来越多，操作系统进程调度和切换的频率也越来越高，系统的压力也会越来越大。因此，一般情况下，PPC方案能处理的并发连接数量最大也就几百。 prefork PPC模式中，当连接进来时才fork新进程来处理连接请求，由于fork进程代价高，用户访问时可能感觉比较慢，prefork模式的出现就是为了解决这个问题。 顾名思义，prefork就是提前创建进程（pre-fork）。系统在启动的时候就预先创建好进程，然后才开始接受用户的请求，当有新的连接进来的时候，就可以省去fork进程的操作，让用户访问更快、体验更好。prefork的基本示意图是： prefork的实现关键就是多个子进程都accept同一个socket，当有新的连接进入时，操作系统保证只有一个进程能最后accept成功。但这里也存在一个小小的问题：“惊群”现象，就是指虽然只有一个子进程能accept成功，但所有阻塞在accept上的子进程都会被唤醒，这样就导致了不必要的进程调度和上下文切换了。幸运的是，操作系统可以解决这个问题，例如Linux 2.6版本后内核已经解决了accept惊群问题。 prefork模式和PPC一样，还是存在父子进程通信复杂、支持的并发连接数量有限的问题，因此目前实际应用也不多。Apache服务器提供了MPM prefork模式，推荐在需要可靠性或者与旧软件兼容的站点时采用这种模式，默认情况下最大支持256个并发连接。 TPC TPC是Thread Per Connection的缩写，其含义是指每次有新的连接就新建一个线程去专门处理这个连接的请求。与进程相比，线程更轻量级，创建线程的消耗比进程要少得多；同时多线程是共享进程内存空间的，线程通信相比进程通信更简单。因此，TPC实际上是解决或者弱化了PPC fork代价高的问题和父子进程通信复杂的问题。 TPC的基本流程是： 父进程接受连接（图中accept）。 父进程创建子线程（图中pthread）。 子线程处理连接的读写请求（图中子线程read、业务处理、write）。 子线程关闭连接（图中子线程中的close）。 注意，和PPC相比，主进程不用“close”连接了。原因是在于子线程是共享主进程的进程空间的，连接的文件描述符并没有被复制，因此只需要一次close即可。 TPC虽然解决了fork代价高和进程通信复杂的问题，但是也引入了新的问题，具体表现在： 创建线程虽然比创建进程代价低，但并不是没有代价，高并发时（例如每秒上万连接）还是有性能问题。 无须进程间通信，但是线程间的互斥和共享又引入了复杂度，可能一不小心就导致了死锁问题。 多线程会出现互相影响的情况，某个线程出现异常时，可能导致整个进程退出（例如内存越界）。 除了引入了新的问题，TPC还是存在CPU线程调度和切换代价的问题。因此，TPC方案本质上和PPC方案基本类似，在并发几百连接的场景下，反而更多地是采用PPC的方案，因为PPC方案不会有死锁的风险，也不会多进程互相影响，稳定性更高。 prethread TPC模式中，当连接进来时才创建新的线程来处理连接请求，虽然创建线程比创建进程要更加轻量级，但还是有一定的代价，而prethread模式就是为了解决这个问题。 和prefork类似，prethread模式会预先创建线程，然后才开始接受用户的请求，当有新的连接进来的时候，就可以省去创建线程的操作，让用户感觉更快、体验更好。 由于多线程之间数据共享和通信比较方便，因此实际上prethread的实现方式相比prefork要灵活一些，常见的实现方式有下面几种： 主进程accept，然后将连接交给某个线程处理。 子线程都尝试去accept，最终只有一个线程accept成功，方案的基本示意图如下： Apache服务器的MPM worker模式本质上就是一种prethread方案，但稍微做了改进。Apache服务器会首先创建多个进程，每个进程里面再创建多个线程，这样做主要是为了考虑稳定性，即：即使某个子进程里面的某个线程异常导致整个子进程退出，还会有其他子进程继续提供服务，不会导致整个服务器全部挂掉。 prethread理论上可以比prefork支持更多的并发连接，Apache服务器MPM worker模式默认支持16 × 25 = 400 个并发处理线程。 小结 今天我为你讲了传统的单服务器高性能模式PPC与TPC，希望对你有所帮助。 这就是今天的全部内容，留一道思考题给你吧，什么样的系统比较适合本期所讲的高性能模式？原因是什么？ 欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！） 原文 19 | 单服务器高性能模式：Reactor与Proactor 专栏上一期我介绍了单服务器高性能的PPC和TPC模式，它们的优点是实现简单，缺点是都无法支撑高并发的场景，尤其是互联网发展到现在，各种海量用户业务的出现，PPC和TPC完全无能为力。今天我将介绍可以应对高并发场景的单服务器高性能架构模式：Reactor和Proactor。 Reactor PPC模式最主要的问题就是每个连接都要创建进程（为了描述简洁，这里只以PPC和进程为例，实际上换成TPC和线程，原理是一样的），连接结束后进程就销毁了，这样做其实是很大的浪费。为了解决这个问题，一个自然而然的想法就是资源复用，即不再单独为每个连接创建进程，而是创建一个进程池，将连接分配给进程，一个进程可以处理多个连接的业务。 引入资源池的处理方式后，会引出一个新的问题：进程如何才能高效地处理多个连接的业务？当一个连接一个进程时，进程可以采用“read -> 业务处理 -> write”的处理流程，如果当前连接没有数据可以读，则进程就阻塞在read操作上。这种阻塞的方式在一个连接一个进程的场景下没有问题，但如果一个进程处理多个连接，进程阻塞在某个连接的read操作上，此时即使其他连接有数据可读，进程也无法去处理，很显然这样是无法做到高性能的。 解决这个问题的最简单的方式是将read操作改为非阻塞，然后进程不断地轮询多个连接。这种方式能够解决阻塞的问题，但解决的方式并不优雅。首先，轮询是要消耗CPU的；其次，如果一个进程处理几千上万的连接，则轮询的效率是很低的。 为了能够更好地解决上述问题，很容易可以想到，只有当连接上有数据的时候进程才去处理，这就是I/O多路复用技术的来源。 I/O多路复用技术归纳起来有两个关键实现点： 当多条连接共用一个阻塞对象后，进程只需要在一个阻塞对象上等待，而无须再轮询所有连接，常见的实现方式有select、epoll、kqueue等。 当某条连接有新的数据可以处理时，操作系统会通知进程，进程从阻塞状态返回，开始进行业务处理。 I/O多路复用结合线程池，完美地解决了PPC和TPC的问题，而且“大神们”给它取了一个很牛的名字：Reactor，中文是“反应堆”。联想到“核反应堆”，听起来就很吓人，实际上这里的“反应”不是聚变、裂变反应的意思，而是“事件反应”的意思，可以通俗地理解为“来了一个事件我就有相应的反应”，这里的“我”就是Reactor，具体的反应就是我们写的代码，Reactor会根据事件类型来调用相应的代码进行处理。Reactor模式也叫Dispatcher模式（在很多开源的系统里面会看到这个名称的类，其实就是实现Reactor模式的），更加贴近模式本身的含义，即I/O多路复用统一监听事件，收到事件后分配（Dispatch）给某个进程。 Reactor模式的核心组成部分包括Reactor和处理资源池（进程池或线程池），其中Reactor负责监听和分配事件，处理资源池负责处理事件。初看Reactor的实现是比较简单的，但实际上结合不同的业务场景，Reactor模式的具体实现方案灵活多变，主要体现在： Reactor的数量可以变化：可以是一个Reactor，也可以是多个Reactor。 资源池的数量可以变化：以进程为例，可以是单个进程，也可以是多个进程（线程类似）。 将上面两个因素排列组合一下，理论上可以有4种选择，但由于“多Reactor单进程”实现方案相比“单Reactor单进程”方案，既复杂又没有性能优势，因此“多Reactor单进程”方案仅仅是一个理论上的方案，实际没有应用。 最终Reactor模式有这三种典型的实现方案： 单Reactor单进程/线程。 单Reactor多线程。 多Reactor多进程/线程。 以上方案具体选择进程还是线程，更多地是和编程语言及平台相关。例如，Java语言一般使用线程（例如，Netty），C语言使用进程和线程都可以。例如，Nginx使用进程，Memcache使用线程。 1.单Reactor单进程/线程 单Reactor单进程/线程的方案示意图如下（以进程为例）： 注意，select、accept、read、send是标准的网络编程API，dispatch和“业务处理”是需要完成的操作，其他方案示意图类似。 详细说明一下这个方案： Reactor对象通过select监控连接事件，收到事件后通过dispatch进行分发。 如果是连接建立的事件，则由Acceptor处理，Acceptor通过accept接受连接，并创建一个Handler来处理连接后续的各种事件。 如果不是连接建立事件，则Reactor会调用连接对应的Handler（第2步中创建的Handler）来进行响应。 Handler会完成read->业务处理->send的完整业务流程。 单Reactor单进程的模式优点就是很简单，没有进程间通信，没有进程竞争，全部都在同一个进程内完成。但其缺点也是非常明显，具体表现有： 只有一个进程，无法发挥多核CPU的性能；只能采取部署多个系统来利用多核CPU，但这样会带来运维复杂度，本来只要维护一个系统，用这种方式需要在一台机器上维护多套系统。 Handler在处理某个连接上的业务时，整个进程无法处理其他连接的事件，很容易导致性能瓶颈。 因此，单Reactor单进程的方案在实践中应用场景不多，只适用于业务处理非常快速的场景，目前比较著名的开源软件中使用单Reactor单进程的是Redis。 需要注意的是，C语言编写系统的一般使用单Reactor单进程，因为没有必要在进程中再创建线程；而Java语言编写的一般使用单Reactor单线程，因为Java虚拟机是一个进程，虚拟机中有很多线程，业务线程只是其中的一个线程而已。 2.单Reactor多线程 为了克服单Reactor单进程/线程方案的缺点，引入多进程/多线程是显而易见的，这就产生了第2个方案：单Reactor多线程。 单Reactor多线程方案示意图是： 我来介绍一下这个方案： 主线程中，Reactor对象通过select监控连接事件，收到事件后通过dispatch进行分发。 如果是连接建立的事件，则由Acceptor处理，Acceptor通过accept接受连接，并创建一个Handler来处理连接后续的各种事件。 如果不是连接建立事件，则Reactor会调用连接对应的Handler（第2步中创建的Handler）来进行响应。 Handler只负责响应事件，不进行业务处理；Handler通过read读取到数据后，会发给Processor进行业务处理。 Processor会在独立的子线程中完成真正的业务处理，然后将响应结果发给主进程的Handler处理；Handler收到响应后通过send将响应结果返回给client。 单Reator多线程方案能够充分利用多核多CPU的处理能力，但同时也存在下面的问题： 多线程数据共享和访问比较复杂。例如，子线程完成业务处理后，要把结果传递给主线程的Reactor进行发送，这里涉及共享数据的互斥和保护机制。以Java的NIO为例，Selector是线程安全的，但是通过Selector.selectKeys()返回的键的集合是非线程安全的，对selected keys的处理必须单线程处理或者采取同步措施进行保护。 Reactor承担所有事件的监听和响应，只在主线程中运行，瞬间高并发时会成为性能瓶颈。 你可能会发现，我只列出了“单Reactor多线程”方案，没有列出“单Reactor多进程”方案，这是什么原因呢？主要原因在于如果采用多进程，子进程完成业务处理后，将结果返回给父进程，并通知父进程发送给哪个client，这是很麻烦的事情。因为父进程只是通过Reactor监听各个连接上的事件然后进行分配，子进程与父进程通信时并不是一个连接。如果要将父进程和子进程之间的通信模拟为一个连接，并加入Reactor进行监听，则是比较复杂的。而采用多线程时，因为多线程是共享数据的，因此线程间通信是非常方便的。虽然要额外考虑线程间共享数据时的同步问题，但这个复杂度比进程间通信的复杂度要低很多。 3.多Reactor多进程/线程 为了解决单Reactor多线程的问题，最直观的方法就是将单Reactor改为多Reactor，这就产生了第3个方案：多Reactor多进程/线程。 多Reactor多进程/线程方案示意图是（以进程为例）： 方案详细说明如下： 父进程中mainReactor对象通过select监控连接建立事件，收到事件后通过Acceptor接收，将新的连接分配给某个子进程。 子进程的subReactor将mainReactor分配的连接加入连接队列进行监听，并创建一个Handler用于处理连接的各种事件。 当有新的事件发生时，subReactor会调用连接对应的Handler（即第2步中创建的Handler）来进行响应。 Handler完成read→业务处理→send的完整业务流程。 多Reactor多进程/线程的方案看起来比单Reactor多线程要复杂，但实际实现时反而更加简单，主要原因是： 父进程和子进程的职责非常明确，父进程只负责接收新连接，子进程负责完成后续的业务处理。 父进程和子进程的交互很简单，父进程只需要把新连接传给子进程，子进程无须返回数据。 子进程之间是互相独立的，无须同步共享之类的处理（这里仅限于网络模型相关的select、read、send等无须同步共享，“业务处理”还是有可能需要同步共享的）。 目前著名的开源系统Nginx采用的是多Reactor多进程，采用多Reactor多线程的实现有Memcache和Netty。 我多说一句，Nginx采用的是多Reactor多进程的模式，但方案与标准的多Reactor多进程有差异。具体差异表现为主进程中仅仅创建了监听端口，并没有创建mainReactor来“accept”连接，而是由子进程的Reactor来“accept”连接，通过锁来控制一次只有一个子进程进行“accept”，子进程“accept”新连接后就放到自己的Reactor进行处理，不会再分配给其他子进程，更多细节请查阅相关资料或阅读Nginx源码。 Proactor Reactor是非阻塞同步网络模型，因为真正的read和send操作都需要用户进程同步操作。这里的“同步”指用户进程在执行read和send这类I/O操作的时候是同步的，如果把I/O操作改为异步就能够进一步提升性能，这就是异步网络模型Proactor。 Proactor中文翻译为“前摄器”比较难理解，与其类似的单词是proactive，含义为“主动的”，因此我们照猫画虎翻译为“主动器”反而更好理解。Reactor可以理解为“来了事件我通知你，你来处理”，而Proactor可以理解为“来了事件我来处理，处理完了我通知你”。这里的“我”就是操作系统内核，“事件”就是有新连接、有数据可读、有数据可写的这些I/O事件，“你”就是我们的程序代码。 Proactor模型示意图是： 详细介绍一下Proactor方案： 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）模拟出来的异步模型。 小结 今天我为你讲了单服务器支持高并发的高性能架构模式Reactor和Proactor，希望对你有所帮助。 这就是今天的全部内容，留一道思考题给你吧，针对“前浪微博”消息队列架构的案例，你觉得采用何种并发模式是比较合适的，为什么？ 欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！） 原文 加餐｜单服务器高性能模式性能对比 你好，我是华仔。 我们架构课的第18讲和第19讲主题是单服务器高性能模式，我们讲了PPC与TPC、Reactor与Proactor，从理论上跟你详细讲述了不同模式的实现方式和优缺点，但是并没有给出详细的测试数据对比，原因在于我自己没有整套的测试环境，也不能用公司的服务器做压力测试，因此留下了一个小小的遗憾。 幸运的是，最近我在学习的时候，无意中在网络上找到一份非常详尽的关于Linux服务器网络模型的详细系列文章。作者通过连载的方式，将iterative、forking（对应专栏的PPC模式）、preforked（对应专栏的prefork模式）、threaded（对应专栏的TPC模式）、prethreaded（对应专栏的prethread模式）、poll、epoll（对应专栏的Reactor模式）共7种模式的实现原理、实现代码、性能对比都详尽地进行了阐述，完美地弥补了专栏内容没有实际数据对比的遗憾。 因此我把核心的测试数据对比摘录出来，然后基于数据来进一步阐释，也就有了这一讲的加餐。我想第一时间分享给你，相信今天的内容可以帮助我们加深对课程里讲过的理论的理解。 下面是作者对7种模式的性能测试对比结果表格，作者在文章中并没有详细地介绍测试环境，只是简单提到了测试服务器是租来的云服务器，CPU只有1核（没有说明具体的CPU型号），对于内存、带宽、磁盘等信息并没有介绍，我们假设这些硬件相关性能都足够。从理论上来说，网络模型的核心性能部件就是CPU，因此如下数据是具备参考意义的。 这张图的数据比较多，如何去看懂这样的性能测试数据表格呢？我来分享一个有用的技巧：横向看对比，纵向看转折。 横向看对比 比如，当并发连接数是1000的时候，可以看出preforking、prethreaded、epoll三种模式性能是相近的，也意味着epoll并不是在任何场景都具备相比其它模式的性能优势。 纵向看转折 比如，prethreaded模式（作者源码中设置了100个线程）在11000并发的时候性能有2200，但12000并发连接的时候，性能急剧下降到只有970，这是什么原因呢？我推测是12000并发的时候触发了C10K问题，线程上下文切换的性能消耗超越了IO处理，成为了系统的处理瓶颈。 按照上述“横向看对比，纵向看转折”的方式，我给你分享一下我的一些解读和发现。 创建进程的消耗是创建线程的消耗的4倍左右。 并发2000以内时，preforked、prethreaded、epoll的性能相差无几，甚至preforked和prethreaded的性能有时候还稍微高一些。 这也是内部系统、中间件等并发数并不高的系统并不一定需要epoll的原因，用preforked和prethreaded模式能够达到相同的性能，并且实现要简单。 当并发数达到8000以上，只有pthreaded和epoll模式能够继续运行，但性能也有下降，epoll的下降更加平稳一些。 prethreaded模式在12000并发连接的时候，性能急剧下降。 推测是触发了C10K问题，线程上下文切换的性能消耗超越了IO处理的性能消耗。 poll模式随着并发数增多稳定下降，因为需要遍历的描述符越多，其性能越低。 类似的还有select模式，作者没有单独写select，因为两者原理基本类似，区别是select的最大支持连接数受限于FD_SETSIZE这个参数。 epoll在并发数超过10000的时候性能开始下降，但下降比较平稳。 这个结论看起来比较简单，但是却隐含着一个关键的设计点：epoll不是万能的，连接数太多的时候单进程epoll也是不行的。这也是为什么Redis可以用单进程Reactor模式，而Nginx必须用多进程Reactor模式，因为Redis的应用场景是内部访问，并发数一般不会超过10000；而Nginx是互联网访问，并发数很容易超过10000。 以上是我从性能对比数据中的一些发现，这些发现能够让我们更进一步理解专栏内容中讲到的理论知识和优缺点对比，这些数据也可以指导我们在实际的架构设计中根据应用场景来选择合适的模式。 最后，我也希望你能掌握“横向看对比，纵向看转折”这个分析技巧。这个技巧在查阅和审核性能测试数据以及各种对比数据的时候，能够帮助你发现很多数据背后隐含的观点和结论。 拓展阅读与学习指南： 原作者的系列文章请参考：Linux Applications Performance: Introduction - Unixism 原作者的测试代码GitHub仓库地址：https://github.com/shuveb/zerohttpd 原作者的代码实现了一个完整的基本功能的HTTP服务器，采用的是短链接的方式，还用到了Redis来保存内容，有的代码逻辑是比较复杂的，尤其是epoll的实现部分。如果你想自己简单的只是验证网络模型的性能，可以去掉其源码中HTTP的实现部分，只是简单地返回“hello world”这样的字符串即可。 补充 11 | 多任务：进程、线程与协程-极客时间 为了改进网络服务器的吞吐能力，现在主流的做法是用 epoll（Linux）或 IOCP（Windows）机制，这两个机制颇为类似，都是在需要 IO 时登记一个 IO 请求，然后统一在某个线程查询谁的 IO 先完成了，谁先完成了就让谁处理。从系统调用次数的角度，epoll 或 IOCP 都是产生了更多次数的系统调用。从内存拷贝来说也没有减少。所以真正最有意义的事情是：减少了线程的数量。 既然不希望用太多的线程，网络服务器就不能用标准的同步 IO（read/write）来写程序。 知名的异步 IO 网络库 libevent 就是对 epoll 和 IOCP 这些机制包装了一套跨平台的异步 IO 编程模型。 后续补充 ...

3.问题/补充

1. 网友评论 不同并发模式的选择，还要考察三个指标，分别是响应时间（RT），并发数（Concurrency），吞吐量（TPS）。 三者关系，吞吐量=并发数/平均响应时间。不同类型的系统，对这三个指标的要求不一样。 三高系统，比如秒杀、即时通信，不能使用。 三低系统，比如ToB系统，运营类、管理类系统，一般可以使用。 高吞吐系统，如果是内存计算为主的，一般可以使用，如果是网络IO为主的，一般不能使用。 2. 公号-技术夜未眠 2018-06-07 BIO：一个线程处理一个请求。缺点：并发量高时，线程数较多，浪费资源。Tomcat7或以下，在Linux系统中默认使用这种方式。可以适用于小到中规模的客户端并发数场景，无法胜任大规模并发业务。如果编程控制不善，可能造成系统资源耗尽。 NIO：利用多路复用IO技术，可以通过少量的线程处理大量的请求。Tomcat8在Linux系统中默认使用这种方式。Tomcat7必须修改Connector配置来启动。 NIO最适用于“高并发”的业务场景，所谓高并发一般是指1ms内至少同时有成百上千个连接请求准备就绪，其他情况下NIO技术发挥不出它明显的优势。 3. Regular 我怎么觉得，凡是高并发请求的系统都适合本节讲的高性能模式？！ 作者回复: 高并发需要根据两个条件划分：连接数量，请求数量。 1. 海量连接（成千上万）海量请求：例如抢购，双十一等 2. 常量连接（几十上百）海量请求：例如中间件 3. 海量连接常量请求：例如门户网站 4. 常量连接常量请求：例如内部运营系统，管理系统 你再尝试分析一下看看😃 网友补充： 颛顼: 为什么门户网站是海量连接，常量请求？一个http请求不是对应一个连接的 张莹莹 > 颛顼: 作者的意思应该是门户网站访问人数多，但都是低频访问 不算帅 > 颛顼 HTTP 有keep-alive, 一定时间内对同一个域名的二次请求浏览器默认是连接复用的。 连接会保持，所以大体上终端的数量决定连接的数量，请求频率对连接数的影响有限 4. W_T 老师在文章和留言里已经透露答案了。 首先，PPC和TPC能够支持的最大连接数差不多，都是几百个，所以我觉得他们适用的场景也是差不多的。 接着再从连接数和请求数来划分，这两种方式明显不支持高连接数的场景，所以答案就是： 1. 常量连接海量请求。比如数据库，redis，kafka等等 2. 常量连接常量请求。比如企业内部网址 作者回复: 回答正确😃😃 个人追减的评论，有问题： 你好，有个问题想请教下，关于常量连接海量请求，比如数据库，这个怎么理解？ 是指业务服务器连接数据库时，这个连接数是常量级？这个连接是可以复用的？不然数据库常量连接海量请求，怎么理解呢？ 另外，如果有海量用户同时访问，业务服务器的连接应该也还是海量的，请求也是海量， 此时单台数据库服务器会报to many connections【mysql 8.0支持最大的连接数是10w】错误吧，解决办法是什么呢？ 读写分离？分散访问【写访问主服务器，读访问从服务器】压力，一主多从，将海量连接分散到不同的db server，如果一主也没办法解决，这个问题，接下来就是分库分表，拆分到不同的server上，从而再次分散访问压力，总的可以支持的最大连接数也变大，请求数也变大了。 一直不太清楚，连接与请求，与进程/线程之间的关系，有知道的同学麻烦赐教下， 不过确实应该好好阅读下老师推荐的《unix网络编程》～ 5. 正是那朵玫瑰 根据华仔回复留言的提示，分析下 1. 海量连接（成千上万）海量请求：例如抢购，双十一等 这样的系统，我觉得这讲所说的模式都不适应，面对海量的连接至少要使用IO复用模型或者异步IO模型，针对海量的请求，无论使用多进程处理还是多线程，单机都是无法支撑的，应该集群了吧。 2. 常量连接（几十上百）海量请求：例如中间件 常量连接，我觉得这讲的模式应该可以适用，如使用TPC的preyhtead模型，启动几十上百的线程去处理连接，应该问题不大吧，但是老师举的列子是中间件是这类系统，我就有点疑问了，是不是中间件系统都可以是阻塞IO模型来实现，比如activemq既支持BIO也支持NIO，但是NIO只是解决了能处理更多的连接，而真正每个请求的处理快慢还得看后面的业务的处理；而阿里的rocketmq也是使用netty这样的NIO框架实现的。但在面对常量连接的场景下，NIO并没有优势啊。 3. 海量连接常量请求：例如门户网站 这种系统我觉得非常适合使用netty这样的NIO框架来实现，IO复用模型可以处理海量的连接，而每个连接的请求数据量会很小，处理会很长快，如华仔说的门户网站，只要简单返回页面即可。 4. 常量连接常量请求：例如内部运营系统，管理系统 这种系统，本讲的模式就很适合了。 水平有限，望华仔指点下。 作者回复: 写的很好，你的疑问补充如下： 1. 常量连接模式下NIO除了复杂一点外，也没有缺点，因此也可以用。 2. 海量连接情况下，单机也要支持很多连接，不然集群成本太高 6. peison 请教一个比较小白的问题…为什么说门户网站是海量连接常量请求的情况？海量连接下为什么会常量请求，一直想不通 作者回复: 海量连接：连接的用户很多 常量请求：每个用户请求数量不多，大部分都是看完一篇文章再去点击另外的文章 7. 孙晓明 李老师，看完文章后查了一下bio和nio，还有一种aio，看的不是太明白，能麻烦您解答一下，并且它与nio的差别在哪里？ 作者回复: BIO：阻塞io，PPC和TPC属于这种 NIO：多路复用io，reactor就是基于这种技术 AIO：异步io，Proactor就是基于这种技术 补充： BIO：Blocking IO NIO：Non-blocking IO AIO：Asynchronous IO 8. LakNeumann 大神， ……纯新手感觉这里读起来已经有点吃力了 ～ 好难啊 作者回复: 这是操作系统基础，可以看看《UNIX网络编程 卷一》 9. 无聊夫斯基 我无法想到ppc比tpc更适合的场景 作者回复: tpc异常时整个服务器就挂了，而ppc不会，所以ppc适合数据库，中间件这类 网友补充： 王二北 突然明白了ngx等为什么要用多进程，而不是多线程 °Ｍagic 可以参考一下nginx的实现 10. 胖胖的程序猿 1. 海量连接（成千上万）海量请求：例如抢购，双十一等 2. 常量连接（几十上百）海量请求：例如中间件 3. 海量连接常量请求：例如门户网站 4. 常量连接常量请求：例如内部运营系统，管理系统 这个不理解，连接和请求有什么区别 作者回复: 一个连接就是TCP连接，一个连接每秒可以发一个请求，也可以发几千个请求 个人问题： William Ning 这个连接是客户端的同一个进程/线程吗？ 不同进程/线程能否复用连接？ 11. 孙振超 本章中提到的几个概念，比如阻塞、非阻塞、同步、异步以及主要的两种方式ppc和tpc，以前都是记住了，今天通过这篇文章是理解了而不再是记住了。 ppc和tpc都是有一个进程来处理链接，收到一个请求就新创建一个进程或线程来处理，在处理完成之前调用方是处于阻塞状态，这种机制决定了单机容量不会太大。 但在文章中提到数据库一般是ppc模式，但数据库通常是连接数少请求量大的场景，为什么会采用这种模式呢？reactor模式为什么不适合数据库？还望老师解惑，多谢！ 作者回复: 数据库连接数少请求量大，所以单线程或者单进程io轮询性能也高，因为一直都有数据处理，不会浪费时间阻塞等待，但数据库的引擎可以是多线程或者多进程，也就是说一条连接的请求交给引擎后，引擎可以是多线程来处理。 reactor适应于连接数很大但活动连接并没有那么多的场景，例如互联网web服务器，reactor功能上也可以用于数据库，只是关系数据库都是历史悠久，久经考验，没有必要把原来的模式改为reactor 12. 云学 希望再多写几篇讲解单机性能优化，比如线程模型，数据库，网络等，猜测下一篇讲IO复用了吧 作者回复: 具体的技术细节点好多，专栏聚焦架构。 一些常见的细节点如下： java：推荐看disruptor的设计论文，包括false sharing, 并发无锁，ring buffer等； 网络：tcp_nodelay，NIO； 内存：内存池，对象池，数据结构 存储：磁盘尾部追加，LSM； 13. Hanson 如果针对自内部系统，是否使用长链接性能损耗较低，毕竟频繁建链拆链性能损耗还是不小的，尤其是TLS的情况下 作者回复: 内部系统长连接多，例如各种中间件，数据库 14. 文竹 PPC适合对稳定性要求高，但并发量不大的场景，对于互联网的场景不适合。 TPC支持的并发量大，适合互联网产品场景。对于支持稳定性，需要创建冗余进程。 作者回复: TPC支持的并发量也不大呢 15. 大光头 高吞吐和高稳定是互斥的，如果要高吞吐就要采用prethread模式，如果要高稳定就需要高preprocess，如果要综合，线程进程同时 作者回复: 这就是apache的其中一个模式，线程进程结合 16. 星火燎原 像您说的这种多进程多线程模式好似更加稳定，但是tomcat为什么采用单进程多线程模型呢？ 作者回复: tomcat是java语言开发的，java用线程是最好的 17. DFighting 看大家的评论，对aio、bio和nio讨论的比较多，我也来凑个数： 请求到达服务器到最终处理完毕可以分为3个过程，接受请求+系统处理+结果返回，其中需要切换线程写作的是请求接受后，在系统处理这段时间，连接线程如何做： bio:阻塞调用等待系统处理完毕 nio:不阻塞调用，不断查询结果，其实从结果上来看依然是阻塞等待的一种，只不过是主动点 io复用：一个连接同时处理多个io请求，本质上还是阻塞，不过由多个线程同时阻塞等待转为一个线程阻塞，等待多个io调用结果 aio:连接请求和处理请求完全异步，连接交给系统处理以后，我就可以去处理下一个连接，等待系统处理结果完毕以后，发送消息或者信号异步发送结果返回 其实从本质以上来看，阻塞和非阻塞这两种性能差异感觉不大，多路复用虽然也是阻塞但是它复用了阻塞线程，提高了性能。异步io才是真正实现了连接线程和系统处理线程的并发执行。 以上是我自己的了解，如有不正确的地方，欢迎指正和探讨 作者回复: 异步io性能相比io复用没有明显优势，但操作系统设计比较复杂，目前来看：Linux上主流的是epoll io复用，windows上是IOCP的异步io 18. 咬尾巴的蛇 很感谢分享，我想问下 就是我开一个tomcat，支持tcp请求，然后什么都不做处理，同时有几百个请求是后面连接就进不来了吗，我是新手才开始架构这块，希望能帮忙解释下，非常感谢 作者回复: tomcat应该不是ppc的模式，如果你找一个ppc的服务器，连接满了后新的连接进不来，但旧的连接发送请求是没问题的 19. 网友-互联网老辛 单台数据库服务器可以支撑多少并发？单台nginx 可以支撑多少呢 作者回复: nginx反向代理可以达到3万以上，具体需要根据业务和场景测试 个人补充问题： 请问，这个并发是指并发连接还是并发请求呢。 另外，关于连接超时，这个通常是由谁来做控制呢？ 网友-熊猫酒仙 单方close和双方close应该是全双工与半双工的区别，连接仍然还存在的。 ppc/tpc比较适合系统中担当路由器或容器角色的部分，像nginx，甚至像mongodb集群也有router。 感觉一些部署容器的线程池，应该属于tpc范畴！ 作者回复: close是减少文件描述符引用计数，当socket的文件描述符引用计数为0时，操作系统底层会执行连接关闭操作，全双工和半双工是shutdown操作。 路由器恰恰不适合ppc/tpc，nginx也不是这种模式 20. 琴扬枫 老师好，请教个问题，文中提到的几百连接是在什么样的软硬件环境参数下面呢？谢谢 作者回复: 常见的服务器配置就可以，16核16g以上 21. 落叶飞逝的恋 几百连接的这种性能只适合内部管理系统之类。 作者回复: 中间件也可以，例如数据库，缓存系统等 22. undefined 请教下，PPC和NIO在同一台服务器上是否可以混合使用？redis用单线程处理IO请求时使用多路复用技术,日志持久化时某些操作会fork子进程来实现异步。关于redis单机高性能的设计跟今天的课程接合起来，是否可以简述一下? 作者回复: PPC和NIO不会混用，PPC是指Process Per Connection，不是说用了多进程就是PPC，而是说用进程来处理连接才是PPC。 所以redis用fork来创建持久化进程不是PPC。 23. 钱 课前思考及问题 1：啥是PPC？它怎么提高性能的？ 2：啥是TPC？它怎么提高性能的？ 3：还存在XPC吗？ 课后思考及问题 1：今天讲的知识，感觉是自己的知识盲点，不是很了解。 2：文中核心观点 2-1：高性能架构设计主要集中在两方面： 一是，尽量提升单服务器的性能，将单服务器的性能发挥到极致。 二是，如果单服务器无法支撑性能，设计服务器集群方案。 2-2：架构设计决定了系统性能的上限，实现细节决定了系统性能的下限。 2-3：服务器高性能的关键之一就是服务器采取的并发模型，并发模型有如下两个关键设计点： 服务器如何管理连接，和I/O模型相关，I/O 模型：阻塞、非阻塞、同步、异步。 服务器如何处理请求，和进程模型相关，进程模型：单进程、多进程、多线程。 详情需参考《UNIX网络编程》《NUIX环境高级编程》《LINUX系统编程》 3：PPC 是 Process Per Connection 的缩写，其含义是指每次有新的连接就新建一个进程去专门处理这个连接的请求，这是传统的 UNIX 网络服务器所采用的模型。 这里没太明白老师讲的是网络通信的通用I/O模型，还是指UNIX特有的，感觉没讲全，也没讲出它怎么实现单服务器的高性能的？ 4：TPC 是 Thread Per Connection 的缩写，其含义是指每次有新的连接就新建一个线程去专门处理这个连接的请求。与进程相比，线程更轻量级，创建线程的消耗比进程要少得多；同时多线程是共享进程内存空间的，线程通信相比进程通信更简单。 5：这块知识差的太多了，感觉听完老师的讲解，发现自己对于进程、线程、子进程、子线程、怎么阻塞的、怎么唤醒的、怎么分配内存空间的、怎么被CPU执行的、网络链接怎么建立的、进程怎么切换的、线程怎么切换的、一个请求怎么发送怎么处理的怎么返回的、长链接怎么保持的这些东西的具体细节都不太清楚。惭愧啊！知耻而后勇，我一定把这些补上来！ 作者回复: 加油 24. 衣申人 有个疑问: 看ppc和tpc模式，最后都是服务器write之后就close，意思是这两种模式都不支持长连接？ 作者回复: 都支持长连接，循环read-处理-write，图中write后可以继续read 25. Hook 老师，我使用 Netty 开发了一个 Java 网络应用程序，是一个长连接的场景。我使用 CentOS、14G 内存、2 个CPU，经过测试发现最高能支持 3 万个并发长连接。 在这 3 万个长连接场景下，CPU利用率大概在 65%左右，而内存剩余不到 2 个G。 这个结果，与网上很多文章介绍的，轻轻松松就能支持百万长连接例子相差很大啊。 结合老师的经验，我这个结果能打几分呢？能给一些优化的方向吗？ 作者回复: 轻松百万是假的吧？这个结果已经是正常结果了 个人观点： 想问下，从上面的结果来看，cpu的利用率并不是很高，也就是cpu并不是限制因素，至于内存，似乎成了限制因素，但是似乎并不是最主要的限制因素，最主要的限制因素，是网络带宽吗？ 26. 天外来客 主要考察连接数，因单机的fd 是有限的，可根据并发连接数考虑是否部署集群！ 作者回复: fd不是关键，关键是进程或者线程数量太多，所占资源和上下文切换很耗费性能 27. 肖一林 对于客户端不多的情况下，可以长连接。对于客户端海量的情况下，只能短连接，还要控制瞬时连接数？反正都要适应ppc和tpc，对吧 作者回复: Reactor，Proactor都可以处理海量长连接 28. 辉 Prethread为啥不用线程池 作者回复: 具体实现可以做成线程池，但线程池涉及到不同连接复用线程时的资源共享问题，处理会复杂一些；如果一个线程只给一个连接用，连接关闭就结束线程，新连接用新线程，实现起来很简单 29. 网友-siwei 同一页面发起多次ajax请求是一个连接还是多个连接？ 作者回复: ajax发的是HTTP请求，所以你要看你具体的HTTP协议版本是1.0还是1.1还是HTTP/2 个人补充： 持久连接在 HTTP/1.1 中是默认开启的，所以你不需要专门为了持久连接去 HTTP 请求头设置信息，如果你不想要采用持久连接，可以在 HTTP 请求头中加上Connection: close。目前浏览器中对于同一个域名，默认允许同时建立 6 个 TCP 持久连接。 极客时间，使用的http协议基本都是1.1 和 2.0， 打开开发者工具，查看network就可以知道，另外，也可以看到很多请求走的是统一连接，从Connection ID就可以知道。

4.参考

TBD

后续补充

...