TinyWebserver的复现与改进（2）：项目的整体框架

上文我们成功运行了代码，本文我们将对项目的整体流程作一下讲解

如果你之前没做过相关的内容，对服务器的⾼并发模型也⼀⽆所知，不建议继续做下去，需要的前置知识有：

• Linux的基本命令（⭐）
• 多进程（⭐）
• 多线程（⭐⭐⭐）
• 网络通信（⭐⭐⭐）

项目的基本流程

我们⾸先还是先看下项⽬的⽂档，看下作者有没有提供代码的框架，有的话就简单了，对着框架图去看代码，可以迅速理清代码的模块组成，快速上⼿其他⼈的代码，然后就可以⾃⼰去写了。

我以项⽬qinguoyi/TinyWebServer at raw_version (github.com)中的框架图为例：

这个webserver流程图详细描述了从接收客户端请求到处理并响应这些请求的一系列复杂过程。下面是对这个流程图的逐步解释：

1. 半同步/半反应堆线程池：这是整个webserver的起点，它提前创建了一个线程池（本质上是一个数组），线程池里面有多个子线程，在最开始的时候，由于没有任务，子线程（即上图的工作线程）都处在空闲状态

   为什么要使用线程池？
   当你需要限制你应用程序中同时运行的线程数时，线程池非常有用。因为启动一个新线程会带来性能开销，每个线程也会为其堆栈分配一些内存等。为了任务的并发执行，我们可以将这些任务任务传递到线程池，而不是为每个任务动态开启一个新的线程

2. epoll监听socket：在主线程中，使用epoll机制来监听socket上的事件（如连接请求）。此时主线程只需要等待有客户端发送数据过来，做出响应，而无需处理具体的任务（这些具体的任务将会由子线程完成）

3. 请求队列：当接收到客户端的请求时，这些请求会被放入请求队列中。这个队列一般是用list实现的，并且使用信号量来唤醒等待处理请求的子线程。

   这里的信号量可以看作是📜待办通知，它告诉子线程有任务需要做了

   而请求队列一般是用list实现，每一个node都可以看作是一个🛠任务，队列中 node的数量 == 信号量

4. 处理任务：当信号量来唤醒（即有任务通知了），请求队列中的任务会被取出并处理。本项目中有3种不同的业务需求，如处理HTTP请求、定时器定时关闭长时间没有活动的客户端、日志输出记录

处理任务这部分可以现暂时不用细究，后面学到这个模块时再一个一个来看

服务器编程的基本框架

上面的框架可以更笼统地概括为下图：

其中主线程是I/O处理模块，逻辑单元是一个个子线程，网络存储单元是之前安装的 MySQL

模块	模块
I/O 处理单元	处理客户连接，读写网络数据
逻辑单元	业务进程或线程
网络存储单元	数据库、文件或缓存
请求队列	各单元之间的通信方式

• I/O 处理单元是服务器管理客户连接的模块。它通常要完成以下工作：等待并接受新的客户端连接，接收客户端数据，将服务器响应数据返回给客户端。但是数据的收发不在 I/O 处理单元中执行，一般在逻辑单元中执行。
• 一个逻辑单元通常是一个进程或线程（本项目中是线程）。它分析并处理客户数据，然后将结果传递给 I/O 处理单元。服务器通常拥有多个逻辑单元（一般线程池已经创建好了多个逻辑单元），以实现对多个客户任务的并发处理。
• 网络存储单元可以是数据库、缓存和文件，但不是必须的。
• 请求队列是各单元之间的通信工具。I/O 处理单元接收到客户请求时，需要以某种方式通知一个逻辑单元来处理该请求。同样，多个逻辑单元同时访问一个存储单元时，也需要采用某种机制来协调处理多个逻辑单元之间的竞争。请求队列通常被实现为线程池的一部分。

总结

本文介绍了项目的总体框架，理清了工作顺序，下一步将会按照这个顺序梳理代码