PHP脚本是否可能被中断？如何保障文件上传后保存与数据库记录操作的原子性？

你提到需要让文件保存和数据库记录写入这两个操作原子执行，避免出现“文件存了但数据库没记录”的不一致情况。除了脚本超时，还有不少场景会打断你的操作，下面我逐一梳理，并给出可落地的预防方案：

一、常见的脚本中断场景 #

• 服务器进程被强制终止：比如运维手动kill PHP-FPM进程、服务器内存不足触发OOM Killer干掉进程、系统突然重启/崩溃。
• 数据库操作异常中断：数据库连接突然断开、SQL执行错误（如字段长度超限、主键冲突）、数据库服务器宕机或网络分区。
• 文件系统异常：磁盘空间耗尽、PHP进程无存储目录写入权限、磁盘IO错误、挂载的远程存储（如NAS）突然断开。
• PHP运行时致命错误：比如调用不存在的函数、内存耗尽触发致命错误、未捕获的Error级异常（PHP 7.0+）。
• 用户主动中断请求：用户上传过程中关闭浏览器、点击取消按钮，导致Web服务器（Nginx/Apache）终止对应的PHP进程。
• 跨网络操作中断：如果数据库或文件存储在远程服务器，网络突然中断会导致其中一个操作失败。

二、原子性实现与中断预防方案 #

核心思路是：让两个操作要么都成功，要么都回滚；同时针对不同中断场景做针对性防护。

1. 基础原子性实现流程（临时文件+数据库事务） #

这是最常用的可靠方案，利用文件系统原子操作和数据库事务的回滚能力：

1. 接收上传文件后，先将文件保存到临时目录（而非最终存储目录），确保文件写入成功（检查move_uploaded_file()的返回值）。
2. 开启数据库事务，执行插入上传记录的SQL语句。
3. 如果事务提交成功，使用rename()函数将临时文件移动到最终存储目录（同一文件系统下rename()是原子操作，不会出现文件半移动的情况）。
4. 若任何一步失败（事务回滚、文件移动失败等），立即删除临时文件，确保没有残留的孤立文件。

2. 针对不同中断场景的防护措施 #

• 进程被终止/OOM Killer：
  • 优化PHP内存配置：调整memory_limit到合理值，避免大文件上传导致内存耗尽；给PHP-FPM设置合适的进程数，防止占用过多系统内存。
  • 配置定时对账任务：定期扫描临时目录和数据库记录，清理孤立的临时文件，或补录未完成的数据库记录（比如临时文件存在但无对应数据库记录，直接删除文件；数据库有记录但文件不在最终目录，标记为异常待人工处理）。
• 数据库异常：
  • 捕获数据库异常：用try-catch包裹数据库操作，一旦捕获到异常立即回滚事务并清理临时文件。
  • 连接重试机制：使用PDO持久连接（ATTR_PERSISTENT），或实现简单的重试逻辑（比如失败后重试2-3次，间隔1秒）。
  • 监控数据库状态：实时监控数据库连接数、宕机情况，及时告警处理。
• 文件系统异常：
  • 上传前预检查：用disk_free_space()检查目标磁盘剩余空间，确保足够存储上传文件；验证PHP进程对存储目录的读写权限。
  • 冗余存储：使用RAID磁盘阵列或云存储的多副本机制，降低磁盘IO错误的影响；如果用远程存储，确保有备份和重试上传的逻辑。
• PHP致命错误：
  • 错误捕获与日志：开启PHP错误日志，记录所有错误；PHP 7.0+可以用try-catch捕获Error级异常，在catch块中回滚事务并清理文件。
  • 限制文件大小：在PHP配置中设置upload_max_filesize和post_max_size，同时在代码中检查文件大小，避免超大文件耗尽内存。
• 用户主动中断请求：
  • 忽略用户中断：在脚本开头设置ignore_user_abort(true)，这样即使用户关闭浏览器，脚本仍会继续执行完成。
  • 合理设置超时：配合set_time_limit()设置足够长的超时时间（比如根据预期最大文件大小设置，避免无限运行）。
• 跨网络操作中断：
  • 远程数据库：使用支持重试的数据库客户端，或自己实现重试逻辑，避免单次网络波动导致操作失败。
  • 远程存储：先将文件存到本地临时目录，再异步上传到远程存储；数据库记录先标记为“待上传”，上传成功后再更新状态为“完成”，失败则触发重试。

3. 最终一致性兜底方案 #

如果严格的原子性难以实现（比如跨多个独立系统），可以用对账补偿机制保障最终一致性：

• 定时任务每天扫描数据库中的上传记录，检查对应文件是否存在于存储目录。
• 同时扫描存储目录，找出没有对应数据库记录的孤立文件，进行清理或标记异常。
• 对异常记录（比如文件缺失、数据库记录缺失），可以自动修复或触发人工告警。

内容的提问来源于stack exchange，提问作者William Entriken