Redis Pub/Sub仅适用于无持久化、无ACK的轻量广播（如配置通知），而可靠分布式广播应使用RabbitMQ topic exchange或PHP-Enqueue框架。
用 Redis pub/sub 实现轻量级广播，但别当主力
Redis 的 PUBLISH / SUBSCRIBE 命令能快速搭出广播通道，适合单机或小流量场景，比如配置变更通知、内部服务心跳同步。但它不保证消息持久化——服务重启后未消费的消息直接丢失；也不支持 ACK 确认，无法知道谁收到了、谁断连了。
常见错误现象：subscribe 连接被意外关闭后收不到新消息；多个 PHP-FPM 进程各自 subscribe 会重复消费；用 phpredis 扩展时没设 setOption(REDIS_OPT_READ_TIMEOUT, -1)，连接频繁超时断开。
实操建议：
- 只用于「丢了也无妨」的低价值通知，比如「刷新缓存」指令
- 订阅端必须用长生命周期进程（如
php artisan queue:work --daemon改写版），不能跑在普通 Web 请求里 - 频道名加前缀隔离环境，例如
prod:notify:config_update，避免测试和生产混用 - 别依赖它做任务分发——没有重试、没有死信、没有路由策略
用 RabbitMQ topic exchange 做真正的发布订阅
RabbitMQ 的 topic 类型 exchange 是 PHP 做分布式广播最稳的选择。它允许订阅者按模式匹配频道（如 user.*.created 或 order.#），天然支持一对多、多对多，且所有消息可持久化、可确认、可路由到多个队列。
立即学习“PHP免费学习笔记（深入）”；
关键点在于：发布者只发给 exchange，不关心谁在听；每个订阅者声明自己的专属队列 + 绑定键（binding key），RabbitMQ 自动完成分发。这和 Redis 的“中心广播”有本质区别。
实操建议：
- 用
php-amqplib而不是amqp扩展——后者已多年未维护，php-amqplib支持 AMQP 0.9.1 全特性且活跃更新 - 声明 exchange 时设
durable=true，队列也要durable=true，否则服务重启后绑定关系丢失 - 消费者启动时先
queue_bind再basic_consume，避免消息在绑定前就进队列然后被丢弃 - 不要把业务逻辑塞进消费者回调里，用独立命令类封装，便于单元测试和复用
PHP-Enqueue 框架怎么绕过底层细节直接用广播
如果你用的是 Laravel 或 Symfony，php-enqueue 就是省事方案。它抽象掉 RabbitMQ/Redis/Kafka 的差异，统一用 Topic 概念表达广播意图。你写一次代码，换配置就能切后端，不用改业务逻辑。
容易踩的坑：enqueue:consume 命令默认不自动创建 topic，得手动执行 php bin/console enqueue:create-topic user.registered；另外它的 sendEvent 方法默认走异步，如果想立刻触发（比如调试时），要加 ['immediate' => true] 参数。
实操建议：
- 在
config/packages/enqueue.yaml中明确指定transport: 'amqp'或'redis'，别依赖 auto-detect - 广播事件类必须实现
Enqueue\TopicBasedEventInterface，否则路由失败静默丢弃 - 用
enqueue:routes命令检查当前绑定是否生效，比翻日志快得多 - 别在 Web 请求中调用
producer->sendEvent()后立刻sleep(1)等结果——这是典型同步思维误用异步设施
为什么 Swoole WebSocket 不该用来做任务广播
有人用 Swoole\WebSocket\Server 在内存里维护客户端列表，然后 foreach 推送消息，看起来像广播。但它本质是 TCP 连接管理，不是消息系统：没持久化、没重试、没跨进程同步、没背压控制。一旦连接数上万，推送延迟飙升，还可能触发 max_coroutine 限制直接崩溃。
真实场景下，这种方案只适用于「同一台机器+几百个在线用户+消息不重要」的内部看板。一旦涉及订单状态变更、支付结果通知等，必须交给 RabbitMQ 或 Enqueue 这类带事务语义的组件。
实操建议：
- WebSocket 只传轻量元数据（如
{"event":"order_updated","id":"ORD-123"}），让前端自己再拉详情 - 绝不在
onMessage回调里做数据库写入或远程 HTTP 调用——阻塞协程，拖垮整个服务 - 如果真要用 WebSocket 做广播中枢，务必配合 Redis Pub/Sub 做跨机器通知，Swoole 进程只负责本机连接投递
