Node.js libuv运行原理详解：架构与异步I/O机制

libuv架构与异步I/O机制解析

前言

这是关于Node.js运行原理系列的第七篇文章。在此之后，短期内将暂停该系列的更新，转而挖掘新的技术方向，例如RPG Maker MV、区块链及云计算等领域的相关研究与教程。

回归主题，异步编程的核心难点在于请求发起与响应返回并非按线性顺序发生。以HTTP服务器为例，异步机制赋予了服务器处理高并发的能力，使其能够以极低的资源消耗持续接收和处理请求。然而，快速处理请求并不等同于快速返回响应，因此高并发并不直接等同于低延迟反馈。

在Node.js环境中，libuv库为异步编程提供了底层实现支持。它为内置模块（builtin modules）提供了相应的API，用于支撑请求处理与数据返回的异步流程。

本文主要从两个维度探讨libuv的运行机制：

1) libuv的整体架构设计。

2) 通过具体案例，从细节层面分析libuv如何针对不同I/O请求采用差异化策略，以完成异步请求与数据返回。

Libuv的整体架构

Libuv的架构

从架构图示来看，libuv的处理流程可分为左右两部分：左侧主要处理Network I/O相关的请求，右侧则涵盖File I/O、DNS操作以及用户代码的执行部分。

上图展示了libuv内部的具体执行流程，涉及的代码逻辑较为简洁，主要包含两个示例部分：

1. server.listen()：这是在创建TCP服务器时通常最后执行的代码，主要用于指定服务器监听的端口号以及定义回调函数。

2. fs.open()：用于以异步方式打开文件。

选择这两个示例的原因在于libuv架构图直观地展示了其对Network I/O和File I/O采用截然不同的处理机制。

上图右半部分主要划分为两个核心组件：

1. 主线程：这是Node.js启动时执行的初始线程。Node启动过程中会完成一系列初始化动作，包括启动V8引擎，随后进入事件循环。

2. 线程池：线程池的大小可通过环境变量UV_THREADPOOL_SIZE进行配置，最大值限制为128个线程，默认值为4个线程。

Network I/O处理机制

Network I/O

V8引擎从执行server.listen()开始，进而调用内置模块Tcp_wrap的相关过程。

在建立TCP连接的过程中，libuv直接介入Tcp_wrap.cc文件中的TCPWrap::listen()调用，从执行uv_listen()开始，直至调用uv_io_start()结束。这一过程看似短暂，实则类似于Linux内核的中断处理机制。

uv_io_start()负责将句柄（handle）插入到待处理的water queue中。这种设计的优势在于请求能够立即得到响应。中断处理机制中的下半部分与数据处理操作类似，最终交由主线程完成后续处理。

代码逻辑相对简单，主要检查loop中是否包含特定的handle，若存在则遍历default loop进行处理。

File I/O处理机制

File I/O

接下来我们深入研究File I/O的处理机制。

与Network I/O类似，应用所依赖的fs模块背后由内置模块Node_file.cc提供支持。Node_file.cc包含了诸如open、read、write、chmod、chown等常用文件操作接口，且均支持异步模式。我们将通过Node_file.cc中的Open()函数来剖析其具体实现细节。

若使用Source Insight等代码阅读工具跟踪调用顺序，可以清晰地发现，在异步模式下，Open()函数经过一系列辅助操作后，会进入uv_fs_open()函数，并传入一个FSReqWrap对象。

FSReqWrap()从命名即可看出，这是一个与文件系统（FS）相关的封装对象。它基于某种现有机制来实现与FS相关的请求操作，该机制即为ReqWrap。在深入理解之前，建议参考图6，图中完整展示了FSReqWrap类的继承关系。

除了FSReqWrap，还存在其他类型的Wrap，例如PipeConnectWrap、TCPConnectWrap等。每种Wrap服务于特定的请求类型。然而，这些Wrap主要体现Node自身的行为，与libuv直接相关的是图中所示的FSReqWrap关键数据结构uv_fs_s req__。

让我们回到uv_fs_open()函数。在调用该函数时，req__作为重要参数被传入。在uv_fs_open()内部，req__被添加到work queue的末尾。图3所示线程池中的线程会领取这些请求进行处理。每个request类似于一个粘贴板，它将event loop、work queue、每个请求的处理函数（work()）以及请求结束后的处理函数（done()）绑定在一起。这种绑定操作在uv__work_submit()中完成。例如，对于上述req__，其绑定的work()为uv__fs_work()，done()为uv__fs_done()。

这里有一个值得额外关注的问题：线程池究竟在何时建立？

答案是：在第一次异步调用uv__work_submit()时建立。

每个线程的入口函数是Threadpool.c中的worker()。其工作逻辑较为简单，即依次从work queue中取出请求，并执行绑定在该请求上的work()函数。那么，前文提到的绑定在请求上的done()函数在哪里执行呢？这是一个有趣的机制：libuv通过uv_async_send()通知event loop去执行相应的回调函数，即绑定在request上的done()函数。uv__work_done()负责完成这一操作。

uv_async_send()与主线程之间通过PIPE进行通信。

在本小节中，我以FSReqWrap及Open()函数为例，描述了libuv处理File I/O请求所涉及的各项操作：

建立thread pool（仅建立一次） 在每个请求req__上绑定与其相关的event loop、work queue、work()函数以及done()函数。thread worker()负责处理work queue中的每个请求，并执行work()函数。通过uv_async_send()通知event loop执行done()函数。

以上便是本次分享的核心知识点，感谢大家对本站的支持。