Nginx reload时共享内存zone数据丢失是设计行为，非bug：新worker初始化空zone，旧zone数据不迁移；需用Redis兜底、分离配置或预热等方案缓解。
平滑重载（nginx -s reload）时共享字典（shared dictionary / shared memory zone）丢失数据，本质是 Nginx 重启 worker 进程时，旧 zone 中的键值未迁移至新 worker，而新 worker 初始化空 zone，导致限流、缓存、连接统计等状态清零。这不是配置错误，而是设计行为——Nginx 的共享内存区不跨 reload 持久化，必须靠外部机制或配置规避。
确认是否真发生了共享字典丢失
别直接假设“reload 就丢”，先验证现象是否匹配：
- 限流模块（
limit_req）在 reload 后大量请求显示miss状态，但客户端 IP 分布未变，且此前已稳定命中hit或rejected - 使用
$limit_req_status或$limit_conn_status记录到 access.log，发现 reload 时间点后所有 key 都从头计数（如 excess 值归零、重置计时） - 自定义 Lua 模块（如
resty.lrucache或shared_dict）中存的数据在 reload 后查不到，且无报错日志 - 对比 reload 前后
nginx -T | grep zone=输出一致，排除配置被覆盖
共享字典无法跨 reload 持久化的根本原因
Nginx 的 shared memory zone 是 worker 进程启动时在内存中分配的一块区域，master 进程不持有其内容。reload 时：
- 旧 worker 继续服务存量请求，其 zone 数据仍有效，直到连接结束
- 新 worker 启动时重新初始化 zone，内容为空
- zone 内容不会从旧 worker 复制/同步到新 worker —— Nginx 不提供该能力
- 因此，“丢失”是预期行为，不是 bug；所谓“数据保留”只能靠业务层兜底或换用持久化方案
缓解与替代方案
不能阻止丢失，但可降低影响或绕过依赖：
-
延长 zone 生效窗口：对限流类场景，增大
burst和nodelay容忍度，让短时间 reload 不触发大量拒绝；例如limit_req zone=ip burst=200 nodelay; -
改用外部状态存储：将关键状态（如登录态、频控计数）下沉到 Redis，Nginx 仅做代理和简单校验；Lua 模块可用
resty.redis直连，避免 shared_dict 单点失效 -
避免 reload 触发关键状态重置：把含
limit_req_zone、limit_conn_zone、map等依赖共享内存的配置，与常变动的路由、SSL 配置分离；只在必要时 reload，非必要用include动态加载（如include /etc/nginx/conf.d/dynamic/*.conf;） -
升级到 OpenResty + lrucache + fallback：若用 Lua，可用
lrucache做本地快速兜底，再 fallback 到 Redis；reload 后 cache 清空，但业务逻辑仍可降级运行
特别注意 Lua shared_dict 的陷阱
很多人以为 shared_dict 是“全局持久”的，其实：
- 它只是当前 worker 进程内共享，不跨进程，更不跨 reload
- worker 进程退出时，其中所有
shared_dict数据立即销毁 - 即使设置了
lua_shared_dict my_cache 10m;，reload 后新 worker 的my_cache仍是空的 - 若业务强依赖该 dict 存活，必须在 init_by_lua* 阶段预热，或改用
lua-resty-lock+ Redis 实现分布式初始化
