Nginx reload过程大致可以分为：1 master从磁盘文件加载配置文件 2 fork新worker 3 给老worker发管道消息或者信号退出。 如果在1~3之间有dyups请求requestA更新某个upstream，大概率会被老worker执行，dyups模块在进程初始化的时候直接清空了共享内存中的消息队列&进程同步状态，所以requestA的变更就不会及时生效了。 近期在生产环境遇到了这个问题，这块从设计上是如何考量的，有好的优化方式么
补充下：本地有agent服务会持久化upstream配置
不销毁老的共享内存会存在一些问题（如新老worker同时操作shm、临界资源等）所以在reload的时候直接销毁老的memory，重新申请新的共享内存。 目前想到的解决方案就是：在reload前进行推送upstream的信息进行本地持久化、然后在进行reload。这样新操作直接从本地加载、避免操作信息丢失。
这个是reload过程中的dyups灌入导致的问题，并不是dyups灌入和持久化顺序的问题，所以 “在reload前进行推送upstream的信息进行本地持久化、然后在进行reload” 这个并不能解决。目前我们采用了下面的方式：检测一定间隔内（几秒内）的reload事件，如果存在reload事件，agent服务同步阻塞消息更新，等待指定间隔后，再继续消息更新。
我们是部署了一个监控，当发现dyups和upstream以及ip列表来源不匹配时再次执行dyups灌入修复dyups内存内容，当然有滞后