RabbitMQ-PHP多消费者异常：Office转PDF任务执行异常

1. 多消费者场景下日志未捕获是否与shell_exec有关？ #

大概率和shell_exec的特性或使用方式直接相关，常见原因包括：

• stderr输出未捕获：shell_exec仅能捕获命令的stdout输出，而LibreOffice执行时的错误信息（如转换失败、资源不足提示）通常输出到stderr。单消费者场景下转换成功率高，这类错误输出少，问题未暴露；多消费者并发执行时，系统资源紧张导致转换出错概率上升，错误信息未被捕获，后续日志写入逻辑因无有效输出或错误未处理而跳过，最终数据库无日志记录。
• 命令执行失败返回null：当多个消费者同时调用shell_exec启动LibreOffice，系统CPU、内存或文件句柄耗尽时，LibreOffice进程无法正常启动，shell_exec会返回null。如果代码中未判断返回值就执行日志写入，会直接导致日志缺失。
• 进程阻塞导致日志写入中断：shell_exec是阻塞调用，多消费者并发时，部分进程可能因LibreOffice执行超时卡住，导致后续日志写入代码无法执行；或者数据库连接因长时间占用被断开，无法完成日志写入。

解决建议：

• 替换shell_exec为exec或proc_open，同时捕获stdout和stderr，示例：

  $command = 'libreoffice --headless --convert-to pdf /path/to/target.file 2>&1';
  exec($command, $output, $returnCode);
  // $output包含所有输出信息，$returnCode为命令退出码（0为成功，非0为失败）
  

• 强制将命令的stderr重定向到stdout（命令末尾加2>&1），确保所有输出都能被捕获；
• 增加错误判断逻辑，无论转换成功与否，都将returnCode、output等信息写入数据库日志，避免遗漏错误场景。

2. 为何多消费者未按预期并行处理任务？ #

问题可能由RabbitMQ配置、PHP代码逻辑或系统资源限制共同导致，具体排查方向如下：

RabbitMQ层面 #

• 未正确发送ACK确认：如果worker代码中处理完任务后未调用basic_ack，或者在ACK之前进程崩溃/卡住，RabbitMQ会将任务标记为Unacked，不会分发给其他消费者。检查worker.php是否在任务处理完成（包括日志写入）后，执行了$channel->basic_ack($msg->getDeliveryTag());，且用try/catch包裹逻辑，确保异常场景下也能发送ACK或NACK（比如$channel->basic_nack($msg->getDeliveryTag(), false, true);让任务重新入队）。
• Prefetch Count设置不合理：如果未设置basic_qos，消费者会一次性获取队列中所有任务，可能出现少数消费者占用全部任务、其他消费者闲置的情况。建议显式设置$channel->basic_qos(null, 1, null);，让每个消费者一次只处理一个任务，确保任务均匀分发。

PHP代码层面 #

• 数据库连接共享导致阻塞：如果database.php中的数据库连接是全局初始化的，多个worker进程会共用同一个连接实例，引发连接竞争，部分进程因等待连接而阻塞，无法并行处理任务。每个worker进程应单独初始化数据库连接，避免共享连接。
• 未捕获异常导致进程崩溃：如果worker代码未捕获shell_exec、数据库操作等环节的异常，进程会直接退出，RabbitMQ会将未ACK的任务重新分发，但频繁崩溃会导致任务反复处于Unacked状态，看起来像是未并行处理。建议用try/catch包裹整个任务处理逻辑，捕获异常后记录日志并发送NACK。

系统资源层面 #

• CentOS系统资源耗尽：多个消费者同时启动LibreOffice进程会占用大量CPU和内存，当系统资源耗尽时，部分LibreOffice进程无法启动，worker进程卡住，导致任务Unacked。可通过top查看资源使用情况，通过ulimit -n调整文件句柄限制，或用进程池控制同时运行的LibreOffice进程数量。
• 文件锁冲突：如果多个worker进程同时操作同一目录（如上传文件存储目录），可能出现文件锁冲突，导致进程阻塞。确保每个任务的文件路径唯一，避免多个进程操作同一文件。

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