Nginx Worker Process 通过绑定 CPU 核心、匹配物理核心数、优化数据布局等手段提升 CPU 缓存（L1/L2）命中率，降低 L2 缓存未命中率 15%–30%，而非管理 Redis 等内存缓存。
Nginx 的 Worker Process 本身不直接管理“内存缓存”（如 Redis 或 Memcached），但它能显著提升 CPU 缓存（L1/L2）命中率，从而加速请求处理——这本质是靠减少缓存失效、稳定数据局部性来实现的。
worker_processes 要匹配物理核心数
每个 worker 进程默认倾向于在单个 CPU 核心上调度。设为物理核心数（比如 4 核就设 worker_processes 4），能让每个 worker 长期驻留在固定核心，反复复用该核心的 L1 指令缓存和 L2 数据缓存。
- 设为 auto 是安全选择，Nginx 会读取 /proc/cpuinfo 自动识别物理核数
- 避免设成超线程逻辑核总数（如 4 核 8 线程时设为 8），除非实测轻量 I/O 场景下收益明显
- 容器或 VM 中需以宿主机实际分配的 vCPU 数为准，不能只看 top 显示的逻辑 CPU
必须启用 worker_cpu_affinity 绑定核心
仅靠 worker_processes 不够——内核调度器仍可能把进程迁移到其他核心，导致缓存热数据丢失。显式绑定可锁住位置：
- 例如 4 核机器： worker_cpu_affinity 0001 0010 0100 1000;
- 推荐用十六进制掩码（如 0101 1010）提高可读性，对应第 0、2、5、7 核
- 云环境缩容后要同步更新配置，否则 Nginx 启动失败（绑定到不存在的核心）
配合减少内存访问抖动
CPU 缓存效率还取决于 worker 内部的数据布局是否紧凑：
- 调小 worker_connections（如从 10240 改为 4096），降低连接结构体在内存中分散分布的概率
- 对静态资源服务，开启 sendfile on 和 tcp_nopush on，绕过用户态拷贝，避免污染 CPU 缓存
- 旧版本可开 accept_mutex on 减少多 worker 争抢 accept 导致的 cache line 伪共享
别混淆：这不是应用层缓存
上述优化不涉及响应内容缓存（那是 proxy_cache 或 open_file_cache 的事），而是让 Nginx 自身指令执行和连接管理更“缓存友好”。实测在高并发小包场景下，L2 缓存未命中率可下降 15%–30%。
