符号链接切换部署对运行中请求的影响及高可用适配性，与Nginx重载部署方案对比（PHP/Laravel场景）

一、符号链接切换对运行中请求的影响 #

在PHP（尤其是Laravel这类框架）的场景下，符号链接切换确实可能引发棘手问题：

• 当请求已经开始处理时，PHP-FPM进程已经打开了旧构建目录中的部分文件句柄，但如果脚本执行过程中需要动态加载后续文件（比如Laravel的自动加载类、未预编译的视图、中途读取的配置文件等），此时符号链接已经指向新构建，进程会读取新构建中的文件。这就会出现同一个请求同时使用新旧版本代码的情况，极易导致类定义冲突、逻辑不一致、甚至直接抛出错误（比如"Class not found"或配置值不匹配）。
• 举个具体例子：如果Laravel请求中途需要加载一个刚在新构建中修改过的模型类，而旧构建中的该模型结构不同，就会引发数据库查询错误或对象属性缺失的问题。

二、符号链接切换是否适合高可用服务？ #

对于要求高可用性、零请求错误的服务来说，这个策略并不合格：

• 高流量场景下，你无法保证切换符号链接时所有正在运行的请求都已完成，必然会有部分请求陷入新旧代码混合执行的状态，产生不可预期的错误或数据不一致。
• 即便你尝试在切换前短暂停止流量，这也违背了高可用"无中断"的核心要求。

三、Nginx重载部署方案的优势（针对PHP/Laravel） #

直接修改Nginx配置指向新构建目录，然后执行service nginx reload（或nginx -s reload）的方案，要可靠得多：

• Nginx的reload是平滑重启：主进程会启动新的worker进程来处理新请求，旧的worker进程会继续处理完当前所有请求后再优雅退出。这就实现了新旧版本的完全隔离——旧请求全程在旧构建环境中执行，新请求全部进入新构建。
• 结合Laravel的部署流程，你可以先在新构建目录中完成所有预操作（比如php artisan config:cache、php artisan route:cache、视图编译等），再修改Nginx配置指向新目录并执行重载，确保新请求拿到的是完全就绪的生产环境代码。
• 这种方式不会中断任何正在处理的请求，也不会出现代码混合的问题，完美适配高可用服务的需求。

额外补充：符号链接方案的补救可能性 #

如果你一定要用符号链接方案，只能通过额外措施降低风险，但依然无法达到高可用标准：

• 切换符号链接前重启PHP-FPM？但service php-fpm restart会直接终止所有正在运行的请求，显然不符合高可用要求。
• 依赖OPcache缓存旧代码？但OPcache的缓存失效策略很难精准控制，且新版本代码的缓存预热也容易出问题，实际操作中依然存在风险。

备注：内容来源于stack exchange，提问作者Ian Flanagan