nginx保障的是关键操作层面的原子性，而非整个请求处理流程的原子性。具体包括：日志写入依赖内核write()≤4096字节的原子边界；共享状态更新使用cpu原子指令；静态资源发布通过文件系统rename实现原子切换。
日志写入：靠内核 write() 的原子边界
每个 worker 进程向同一 access_log 文件写入时，不会出现两行日志内容交叉粘连。根本原因在于 Linux 内核对 ≤4096 字节 的 write() 系统调用提供原子保障：整行日志要么完整写入，要么不写（在缓冲区排队），不会被其他 worker 切开。
- 默认日志格式（含时间、状态码、IP 等）通常远小于此限，天然安全
- 风险来自未截断的大字段，如
$request_body、超长$http_user_agent或嵌套 JSON —— 一旦单行日志超过 4096 字节，内核不再保证原子性，可能产生半截日志或丢失换行符 - 应对方法：用
map截断变量、启用buffer=64k flush=5s合并写入、或改用 per-worker 日志路径
共享状态更新：靠 CPU 原子指令
Nginx 在共享内存中维护连接数、限流计数器、SSL 会话引用等全局状态时，不用互斥锁排队，而是直接使用硬件级原子操作：
-
ngx_atomic_fetch_add(&counter, 1)：安全递增连接计数，多个 worker 同时调用也不会漏计 -
ngx_atomic_cmp_set(&flag, 0, 1)：用于乐观更新标志位（如配置重载通知），失败即重试，无阻塞 - 这些操作在 x86 上编译为
lock xadd、ARM 上为ldrex/strex，由 CPU 硬件保证读-改-写不可分割
静态资源发布：靠文件系统 rename 的原子切换
上百台 Nginx 节点同步前端资源时，“换内容”本身必须原子——不能让用户看到新旧混合的页面。
- 新版本资源先完整写入带时间戳的独立目录（如
/data/static-v20260607） - 本地完成全量 SHA256 校验后，执行
ln -sf /data/static-v20260607 /data/current - 该
rename类操作在绝大多数文件系统上是原子的，毫秒级完成，Nginx root 指向/data/current，无需 reload，用户零感知
注意边界：原子 ≠ 全流程事务
上述保障都针对特定动作，而非整个 HTTP 请求生命周期：
- 一个请求可能已写入部分响应体、又因超时中断，Nginx 不会回退这部分输出
- 原子操作只保护单个整数变量，无法自动确保“连接数+1”和“字节数+1024”这两个更新同时成功
- 复杂逻辑（如缓存回源+写入）仍需模块自行设计同步策略，原子操作只是基础工具
