weixin_43977379的博客

在现代的服务器端编程中，多线程已经是一种广泛应用的技术，它可以将任务并行化从而提高响应时间。一种应用比较广泛的服务器多线程模型是Reactor，也被称为是基于事件的线程模型。详细解读可以参考这一系列文章。与之对应的是Proactor线程模型，它的主要特点则是整个函数逻辑是用回调的链条组成的，这句话可能不太好理解，后面会详细解释；而协程则是一种在同一个线程内实现的异步操作，详细解释可以参考。二者的共同点在于，，下面将详细叙述。

当请求到达网关层时，发现客户端是的请求是上传文件，那么就开始接收，接收一个分块就传递给数据管理层，直到最后一个分块在数据管理层写入成功或者中途某个分块处理失败，数据管理层将该信息返回给网关层，如果失败网关层直接返回用户写入失败，如果成功则向元数据管理层写入元数据，元数据管理层写入成功再返回给网关，直到这时网关层才能返回给用户该文件写入成功的响应。本章根据一个实际的分布式存储系统的写入文件的案例，结合之前讲述的线程模型，实现了一个完整的多线程任务的执行逻辑。

线程池实际上就是为了避免创建销毁线程的开销而使用的一种机制，本质上就是一个生产者-消费者模型，首先创建好一定数量的线程，当没有任务的时候就处于休眠状态，当有任务加入到任务队列中时就从中取出并执行。为什么要考虑这两个问题？当上传大文件的时候，文件会分块进行上传，一个socket将会有连续的数据输入，那么epoll将会一直监听到该socket的可读事件，那么EventLoop就会一直处理这个socket，而从缓冲区读取数据则是阻塞的，在单线程情况下就会阻塞其他socket的处理。

前面的章节介绍了reactor模型的基本结构，也通过代码体现了非阻塞IO带来的益处。不过还遗留了一个问题——线程是一种有限的资源，不可能无限的扩展线程，那么该怎样利用有限的线程资源尽可能的榨干系统的性能，可不可以使用一个连接开启一个线程进行处理？

上接在序章中的最后提到了两个服务器瓶颈的原因：1、能够扩展的线程数量是有限的2、阻塞式的等待socket会让线程一直处于空闲状态（当然socket可以换成其他文件描述符）针对问题1，既然线程的数量是有限的，那我们就尽最大的可能去利用它，榨干它的能力；针对问题2，则可以换一种思路，如果当前的socket没有数据传输过来，那就立即返回一个错误信息，处理下一个建立的连接，然后循环询问所有建立的连接的socket，如果某个socket有数据传输过来就立马进行处理，这就是非阻塞(NIO)的思想。

最近在拜读陈硕的《Linux多线程服务端编程》[1]，目前读到第3章，主要讲常用的服务端的编程模型，其中提到了很多线程模型以及与性能相关的分析，读了之后想实践一下书中提到的理论，也顺便复习一下网络编程的相关内容，于是搜索了很多关于Reactor和Proactor相关的内容，对于里面概念的讲述是可以理解的，但是如果具象化到代码中还是无法第一时间在脑中形成概念。因此想结合书中第三章的讲解，捋一捋多线程服务器的模型以及性能分析，通过C++代码逐步弄明白各种服务端模型和IO模型。

本文是《多线程服务器分析——Reactor线程模型和性能分析》系列的索引。