nginx中ssl_session_cache的“不同步”是误解，shared:ssl:10m配置下master进程分配共享内存，所有worker通过mmap映射同一区域，内置锁保障线程安全，天然同步；关键在启用shared而非同步配置。
nginx 中 ssl_session_cache 的“不同步”其实是个误解——只要正确配置，它在多 worker 进程间天然就是同步的。关键不在于“如何同步”，而在于是否启用了真正的共享机制。
shared 是唯一跨 worker 共享的方式
nginx 默认不启用会话缓存（ssl_session_cache none），所有 worker 进程各自独立、互不影响。一旦配置成 shared:SSL:10m，master 进程就会在启动时分配一块名为 SSL、大小为 10MB 的共享内存区域（shm）。所有 worker 进程通过 mmap 映射访问同一块内存，读写操作由 nginx 内置锁机制保障线程安全。不需要额外插件、无需外部协调。
- 配置必须写在
http块顶层，不能分散在多个server块中重复定义 - 若多个
server都写了shared:SSL:10m，nginx 会合并为一个区域，但参数不一致可能引发未定义行为 - 禁用方式只有
off或none；builtin类型仅限单 worker，多进程下无效
为什么你感觉“没生效”？常见误判点
缓存命中不可见，容易误以为没起作用。真正有效的验证方式不是看日志有没有报错，而是观察实际复用行为：
- 用
openssl s_client -connect example.com:443 -reconnect连续请求，输出中出现Reused, SSL handshake has read 0 bytes才表示复用成功 - 检查
$ssl_session_reused变量：值为.（点）代表复用，0或空代表新建会话 - 若始终是新建会话，优先排查是否客户端不支持 session ID 复用（如某些旧 Android WebView）、或服务端被中间设备（如 WAF）剥离了 session ID
共享内存溢出比“不同步”更常发生
缓存条目本身是共享的，但空间不够时，新会话会挤掉旧条目，导致命中率骤降——这不是同步问题，而是容量不足。估算公式很实用：
- 每秒新建会话数 × 平均存活秒数 × 0.5KB ≈ 所需缓存大小（单位字节）
- 例如：2000 QPS、会话平均存活 3 分钟 → 2000 × 180 × 512 ≈ 184MB，远超默认 10m
- 建议按 50m 或 100m 步进调整，并搭配
ssl_session_timeout 10m控制生命周期，避免长连接长期占位
session tickets 是无状态补充方案
当共享内存持续承压，或需跨多台 nginx 实例复用时，ssl_session_tickets on 是更优选择。它把会话密钥加密后交给客户端保存，服务端不存状态，彻底避开共享内存瓶颈。
- 必须配合
ssl_session_ticket_key定期轮转，防止密钥泄露后历史流量被解密 - 与
shared缓存可并存：客户端优先尝试 ticket，失败再 fallback 到 session ID 查共享内存 - 注意：部分老旧客户端（如 IE8–10）不支持 ticket，需保留 session ID 作为兜底
