PHP跨进程消息分发：观察者模式+Redis队列实现方案

本文深入探讨了PHP中实现跨进程消息分发的实用方案，直击msg_get_queue等系统IPC机制在Web环境（尤其是FPM）下的根本性局限，提出以Redis List（LPUSH/BRPOP）为核心、结合观察者模式进行逻辑解耦的轻量级架构：观察者仅负责安全入队，真正耗时的任务交由常驻CLI消费者异步处理，既保障Web响应速度，又支持横向扩展；同时细致剖析了超时处理、信号安全退出、JSON序列化陷阱及空轮询等极易被忽视却关乎稳定性的关键细节，为构建高可用、易维护的消息分发系统提供了经过生产验证的完整路径。

msg_get_queue 不适合跨进程消息分发，它只在单机、同用户、同 IPC namespace 下有效，且无法被 Web 请求进程（如 FPM）安全访问。真正可行的跨进程分发必须依赖外部中间件——Redis 是最轻量、最常用的选择。

为什么不用系统消息队列（sysvmsg）做跨进程分发

PHP 的 msg_get_queue / msg_send 系列函数依赖系统级 IPC，存在三个硬限制：

• FPM 进程默认无权限创建或访问消息队列，常报 Permission denied 或 Invalid argument
• 不同用户启动的进程（如 www-data 和 root）无法共享同一 ftok key 生成的队列
• 队列生命周期绑定到第一个创建它的进程，Web 请求结束后队列可能被意外销毁

用 Redis List 实现生产者-消费者解耦

Redis 的 LPUSH + BRPOP 组合天然适配任务分发场景，无需额外守护进程或配置。

• 生产者（如控制器）调用 $redis->lpush('task:mail', json_encode($data))
• 消费者（CLI 脚本）循环执行 $redis->brpop('task:mail', 30)，阻塞等待最长 30 秒
• 多个消费者可同时监听同一 key，Redis 自动轮询分发，无需手动负载均衡
• 失败任务可 LPUSH 回原队列或推入 task:mail:failed 专用通道

观察者模式如何与 Redis 队列协同

观察者模式本身不解决跨进程问题，但它能帮你把「触发通知」和「实际分发」逻辑分离。关键在于：观察者只负责写队列，不执行耗时操作。

• 定义一个 MailSentObserver，在订单支付成功后调用 $this->redis->lpush('event:mail', json_encode(['type' => 'order_confirmed', 'order_id' => $id]))
• 另起一个常驻 CLI 进程（如 php worker.php），监听 event:mail 并路由到具体处理类：if ($event['type'] === 'order_confirmed') { (new OrderMailService())->send($event); }
• 避免在观察者里直接调用 Swift_Mailer->send() —— 这会阻塞 Web 响应，且无法横向扩展

容易忽略的边界情况

Redis 队列不是银弹，这几个点不处理好，上线后就会丢任务：

• BRPOP 返回 null 表示超时，不是错误，不能直接 exit 或抛异常
• 消费者进程被 SIGTERM 杀掉前，需主动 UNSUBSCRIBE（若用了 Pub/Sub）或确保最后一条消息已 ACK（若用了 Streams）
• JSON 编码时注意 json_last_error()，含资源句柄、闭包或循环引用的对象会静默失败
• 不要用 RPOP 替代 BRPOP，空轮询会打爆 CPU

今天关于《PHP跨进程消息分发：观察者模式+Redis队列实现方案》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！