nginx 日志无并发争抢因 worker 独立写文件、内核 append 保证原子性；需避免 reload 导致 fd 泄漏，推荐 usr1 重开日志；高吞吐下启用 buffer/flush；pipe 模式需下游支持多路写入。
Nginx 本身通过 worker 进程模型 + 文件追加写入 + 操作系统内核缓冲，天然规避了应用层的日志并发争抢问题，不需要额外加锁或队列。关键在于理解它的日志机制设计，并合理配置避免潜在瓶颈。
日志写入由每个 worker 独立完成
Nginx 启动后，每个 worker 进程都会打开自己的 access_log 和 error_log 文件（除非显式配置为 `stderr` 或 syslog）。这意味着：
- 多个 worker 不会同时往同一个文件描述符写；
- 即使日志路径相同（如 /var/log/nginx/access.log），操作系统会为每个 worker 分配独立的 fd；
- 写操作最终由内核调度，追加模式（O_APPEND）保证偏移定位和写入原子性（对单行日志通常成立）。
避免使用同一文件路径 + 高频重载导致的 fd 泄漏
如果频繁执行 nginx -s reload，而日志文件路径未变，旧 worker 会继续写原文件，新 worker 也打开同名文件——看似“并发写”，实则是多个进程在写同一磁盘文件。虽不报错，但可能引发：
- 日志行交错（极少见，因内核 append 保障单次 write 原子性，但多行日志仍可能穿插）；
- 文件句柄堆积、磁盘空间误判（如 logrotate 未及时通知所有 worker）。
建议做法：
- 配合 logrotate 使用 kill -USR1 信号，让 Nginx 安全重开日志文件；
- 在 logrotate 配置中添加 postrotate nginx -s reopen 或直接发 USR1；
- 不要依赖 reload 触发日志轮转。
高吞吐场景下用 buffer 和 flush 控制写行为
对于万级 QPS 的服务，频繁小 write 会加重 I/O 压力。可通过以下指令优化：
- access_log /path/to/log main buffer=64k flush=1s;
- buffer 启用内存缓冲，累积到大小或超时才刷盘；
- flush 防止缓冲区长时间不落盘，兼顾性能与可靠性；
- 错误日志不支持 buffer，但可调低记录级别（如避免 info 级调试日志上线）。
真正需要隔离的场景：自定义日志 + 变量 + 外部程序
若用 log_format 引入复杂变量，或配合 pipe:/path/to/script 把日志转发给外部进程处理，则并发风险转移到下游：
- pipe 模式下，所有 worker 共享一个管道 fd，需确保接收端能处理多路写入（如用 stdbuf 或异步 I/O）；
- 更稳妥的方式是改用 syslog 协议（syslog:server=127.0.0.1:514），由 syslog daemon 统一收敛和分发。
