msg_get_queue 不适合跨进程消息分发，仅限单机同用户同IPC namespace；Redis是轻量首选，LPUSH/BRPOP实现解耦，观察者模式负责入队，CLI消费者处理，需注意超时、信号、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）无法共享同一
ftokkey 生成的队列 - 队列生命周期绑定到第一个创建它的进程，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 队列不是银弹，这几个点不处理好，上线后就会丢任务：
立即学习“PHP免费学习笔记（深入）”；
-
BRPOP返回null表示超时，不是错误，不能直接exit或抛异常 - 消费者进程被
SIGTERM杀掉前，需主动UNSUBSCRIBE（若用了 Pub/Sub）或确保最后一条消息已 ACK（若用了 Streams） - JSON 编码时注意
json_last_error()，含资源句柄、闭包或循环引用的对象会静默失败 - 不要用
RPOP替代BRPOP，空轮询会打爆 CPU
