简单来说，OpenResty 的核心魔法在于：**让开发者用同步的 Lua 代码逻辑，实现底层的异步非阻塞 I/O**。
以下是 OpenResty 底层原理的深度解析，分为几个核心板块：
---
1. 宏观架构：三位一体
OpenResty 并不是简单的 Nginx + Lua，它的架构可以看作三个层次的融合：
1. 宿主（Host）：Nginx
- 提供 HTTP/TCP 服务器框架。
- 提供基于 epoll (Linux) / kqueue (BSD) 的事件驱动、非阻塞 I/O 模型。
- 负责连接管理、进程管理（Master-Worker 模式）。
2. 引擎（Engine）：LuaJIT
- 即时编译器（JIT），执行效率极高，接近 C 语言。
- 提供 Lua 协程支持，这是实现“同步写法，异步执行”的基础。
- 通过 FFI (Foreign Function Interface) 直接调用 C 函数，减少上下文切换开销。
3. 桥梁（Bridge）：ngx_lua_module
- 这是 OpenResty 的核心组件。它将 Lua 解释器嵌入到 Nginx 的 Worker 进程中。
- 它劫持了 Nginx 的处理阶段，允许在不同的生命周期插入 Lua 代码。
---
2. 核心机制：Cosocket (Coroutine + Socket)
这是 OpenResty 最核心的原理。在传统的 Nginx C 模块开发中，你需要写大量的异步回调（Callback），代码非常复杂且难以维护。而 OpenResty 引入了 **Cosocket**。
原理流程：
当你写下一行代码
local res = redis:get("key") 时，底层发生了什么？1. Lua 调用：Lua 代码发起网络请求（如连接 Redis）。
2. 挂起协程 (Yield)：ngx_lua 模块拦截这个请求，发现是 I/O 操作，于是利用 Lua 的 coroutine.yield() 将当前的 Lua 协程挂起（暂停）。
- 此时，Lua 环境保存了当前的上下文（堆栈、变量等）。
3. 注册事件：ngx_lua 将这个 socket 的文件描述符（fd）和回调函数注册到 Nginx 的事件循环（Epoll）中。
4. 交出控制权：Nginx Worker 进程并没有阻塞，它继续处理其他请求（可能是处理另一个用户的 HTTP 请求）。
- 注意：这就是高并发的来源，单个线程在等待 I/O 时去干别的事了。
5. I/O 完成：当 Redis 返回数据，操作系统触发 Epoll 事件，通知 Nginx。
6. 恢复协程 (Resume)：Nginx 的事件处理函数找到之前挂起的 Lua 协程，利用 coroutine.resume() 恢复它的执行，并将 Redis 返回的数据作为返回值塞给 Lua。
7. 继续执行：Lua 代码从 redis:get 的下一行继续执行，仿佛一切都是同步发生的。
**总结**：用户层的代码是“同步”的（没有回调地狱），但底层的执行是“全异步非阻塞”的。
---
3. Nginx 阶段挂载 (Phases)
OpenResty 并没有生造一套流程，而是完美利用了 Nginx 的 HTTP 处理阶段。
ngx_lua_module 允许你在 Nginx 的不同阶段执行 Lua 代码：- init_by_lua: Nginx Master 启动加载配置时（初始化全局变量）。
- init_worker_by_lua: 每个 Worker 进程启动时（如启动定时器）。
- rewrite_by_lua: 请求重写阶段（转发、修改参数）。
- access_by_lua: 访问控制阶段（防火墙、权限校验）。
- content_by_lua: 内容生成阶段（最常用的阶段，处理业务逻辑，输出响应）。
- header_filter_by_lua: 响应头过滤。
- body_filter_by_lua: 响应体过滤。
- log_by_lua: 日志记录阶段。
**原理**：Nginx 执行到某个阶段时，会检查是否有 Lua 钩子。如果有，就通过 C API 调用 LuaJIT 虚拟机执行对应的 Lua 脚本。
---
4. 内存模型与数据共享
OpenResty 是多进程模型（Nginx Worker），理解内存模型非常重要。
1. Lua VM 隔离：
- 每个 Nginx Worker 进程有一个独立的 LuaJIT 虚拟机（lua_state）。
- Worker A 中的 Lua 全局变量，Worker B 是看不见的。
- 优点：无需加锁，极其高效。
- 缺点：无法通过全局变量跨进程通信。
2. Shared Dict (共享内存)：
- 为了跨 Worker 通信（例如实现全局限流、缓存），OpenResty 提供了 lua_shared_dict。
- 底层：利用 Nginx 的共享内存机制（mmap 映射一块内存），配合自旋锁（Spinlock）保证原子性。
- 所有 Worker 都可以读写这块内存。
3. ngx.ctx：
- 这是一个 Lua table，用于在同一个请求的不同阶段之间传递数据（例如在 access 阶段计算一个值，在 log 阶段打印它）。
- 生命周期随请求结束而销毁。
---
5. 高性能的关键：LuaJIT 与 FFI
OpenResty 快，不仅仅因为异步 I/O，还因为 LuaJIT。
- JIT 编译：LuaJIT 会追踪热点代码（Trace），将其直接编译成机器码，而不是解释执行。
- FFI (Foreign Function Interface)：
传统的 Lua 调用 C 函数需要通过 Lua C API（压栈、出栈），有开销。
- LuaJIT 的 FFI 允许 Lua 代码直接声明 C 数据结构和函数，直接调用 C 库（.so），几乎没有开销。
- lua-resty-core：OpenResty 的新版核心库大量使用 FFI 重新封装了 Nginx 的 C 函数，比旧版的 Lua C API 调用方式更快。
---
6. 总结：OpenResty 的处理全景图
当一个请求到达 OpenResty 时：
1. Nginx 接收连接：Epoll 唤醒某个 Worker。
2. 进入 Lua VM：根据配置进入 access_by_lua 等阶段。
3. 业务逻辑：Lua 脚本开始运行。
4. 遇到 I/O：
- Lua 调用 cosocket。
- 协程挂起，C 栈返回 Nginx 事件循环。
5. Nginx 忙别的：Worker 继续处理其他请求。
6. I/O 也就绪：
- Epoll 通知。
- 恢复协程上下文。
7. 响应数据：Lua 组装数据，通过 ngx.say 发送（这也是非阻塞的，写入 Nginx 的输出缓冲区）。
这就是 OpenResty 能够以极少的资源（CPU/内存）处理数万甚至数十万并发连接的底层原因：**它榨干了 CPU 的每一个时钟周期，不让 CPU 在等待 I/O 上浪费哪怕一微秒。**