分析 upstream 模块是理解 nginx 事件驱动物理指针映射最直接、最扎实的路径，它通过 u→read/write_event_handler、u→peer.get/init、c→r→u 三级链、epoll→event→connection→request→upstream 映射、buffer/chain 指针复用及 dyups/dynamic_resolve 的指针动态更新，完整呈现事件驱动在内存层面的真实实现。
分析 upstream 模块是理解 Nginx 事件驱动物理指针映射最直接、最扎实的路径。它不是抽象讲“回调”或“event loop”，而是把 事件如何绑定到连接、连接如何关联请求、请求如何调度上游操作 这条链路，全部落在真实数据结构和函数调用中。关键不在看多少代码，而在抓住几个物理指针的流转主线。
upstream 初始化时就绑定了事件 handler 指针
当 ngx_http_upstream_create 被调用，它为当前请求分配 ngx_http_upstream_t 结构体，并立即设置：
- u->read_event_handler 和 u->write_event_handler：这两个函数指针决定了后续 socket 可读/可写时该执行哪段逻辑（比如 ngx_http_upstream_process_header 或 ngx_http_upstream_send_request）
- u->peer.get 指向负载均衡选择函数（如 round-robin），而 u->peer.init 会初始化连接池与 peer 链表——这些都基于 ngx_connection_t 和 ngx_event_t 的复用机制
- 整个 upstream 实例最终挂载在 r->upstream，而 r（ngx_http_request_t）本身又嵌套在 c->data（ngx_connection_t *）里，形成 c → r → u 的三级物理指针链
连接建立阶段暴露 epoll 与 connection 的映射关系
ngx_http_upstream_connect 启动 TCP 连接后，若未立即成功，就调用 ngx_event_connect_peer。这个函数做了三件事：
- 从连接池取一个空闲 ngx_connection_t，将其 fd 设置为新 socket，并把 read/write event 的 data 指向该 connection
- 把该 connection 的 write event 添加进 epoll 监听（EPOLLOUT），等待连接完成
- 一旦 epoll_wait 返回 EPOLLOUT 事件，epoll 模块触发该 event 的 handler（即 ngx_event_connect_peer 的回调），再由 upstream 模块继续走 send request 流程
此时，一个 epoll 事件 → 一个 ngx_event_t → 其 data 指向一个 ngx_connection_t → 其 data 又指向一个 ngx_http_request_t → 其 upstream 字段指向 ngx_http_upstream_t。这就是事件驱动在内存层面的真实映射。
响应处理阶段体现 buffer 与 chain 的指针级复用
接收响应时，upstream 不直接 malloc 新内存，而是复用已有缓冲结构：
- u->buffer 是预分配的固定大小 buf（通常 4K），用于暂存响应头；它的 start/end/pos/last 四个指针控制读写位置
- 响应体用 ngx_chain_t 链表组织，每个链节点的 buf 指向一块内存区域；这些 buf 多数来自内存池或共享内存，而非每次 new
- 当 buffering=off 时，u->busy_bufs / u->free_bufs 构成一个简易 ring buffer，通过指针移动实现零拷贝转发
动态解析与健康检查强化了指针生命周期管理
像 dyups 或 dynamic_resolve 这类模块，本质是在运行时修改 upstream 结构中的指针引用：
- dyups 修改 uscf->servers 数组内容，同时更新 peer 链表头指针，但不重建 connection pool
- dynamic_resolve 在 u->resolved 中维护 DNS 缓存结果，其 addrs 字段指向动态分配的地址数组，失败时 fallback 到旧地址指针
- 所有变更都绕不开对 ngx_http_upstream_srv_conf_t 和 ngx_http_upstream_server_t 中指针字段（如 addrs、srv_conf）的原子更新与安全释放
不复杂但容易忽略
