rabbitmq多店铺库存同步需确保消息不丢、路由不漏、消费不卡：消费者须常驻命令行运行，routing_key严格按shop_id+sku_id二维路由，队列与exchange均需持久化，手动ack并绑定事务，禁用guest用户，显式执行queue_bind。
TP5.1/6.x 做多店铺库存同步，RabbitMQ 不是“加个扩展就能跑”，核心矛盾在消息不丢、路由不漏、消费不卡——尤其当 100+ 店铺同时扣减同一商品时，错一个 routing_key 或少一次 ack，库存就对不上。
为什么不能把消费逻辑写进 HTTP 请求里
很多老项目图省事，在控制器里直接 new Producer() 发消息，再调 $channel->basic_consume() 拉消息。结果是：每次用户下单，PHP-FPM 就启一个新消费者进程，连接数暴涨、内存泄漏、ack 无法确认，消息重复投递或静默丢失。
- 消费者必须用 ThinkPHP 命令行启动：
php think rabbitmq:consume，且需配合supervisord或systemd守护，保证常驻不退出 - HTTP 请求只负责发消息（生产者），不能承担消费职责；否则一压测就 Connection refused 或 Too many open files
- TP5.1 没有内置队列命令，得自己写
application/command/RabbitmqConsume.php，并在command.php中注册
多店铺场景下 routing_key 必须带店铺 ID 且严格一致
库存同步本质是「商品 ID + 店铺 ID」的二维路由。用 Direct Exchange 时，routing_key 就是路由命门，任何偏差都会导致消息进错队列甚至消失。
- 推荐格式：
stock.update.{shop_id}.{sku_id}，例如stock.update.8827.10045；所有生产者、消费者、绑定动作必须用完全相同的字符串 - 声明队列时不要硬编码，按店铺动态生成：
$channel->queue_declare('stock_queue_' . $shop_id, false, true, false, false) - 绑定必须显式调用：
$channel->queue_bind($queue_name, $exchange_name, $routing_key)；RabbitMQ 管理界面里建好也不算数 - 调试时用
rabbitmqctl list_bindings --formatter=json | grep stock.update确认绑定键是否含不可见字符（比如 Windows 编辑器留下的 BOM）
消息和队列都得持久化，缺一不可
只设 delivery_mode => 2 不顶用。RabbitMQ 重启后，如果队列没声明为 durable，整个队列结构就没了，消息即使写盘也“无家可归”。
- 队列声明第三个参数必须为
true：$channel->queue_declare('stock_queue_8827', false, true, false, false) - Exchange 声明第四个参数也要
true：$channel->exchange_declare('stock_exchange', 'direct', false, true, false) - 发消息时带上
['delivery_mode' => 2]：new \PhpAmqpLib\Message\AMQPMessage($payload, ['delivery_mode' => 2]) - 别用
guest用户连远程 RabbitMQ——默认只允许localhost，生产环境必须新建用户并赋权：rabbitmqctl add_user shop_sync pass123 && rabbitmqctl set_permissions -p / shop_sync ".*" ".*" ".*"
消费者必须手动 ack，且不能在事务外处理
库存是强一致性场景，消费者拿到消息后如果没处理完就 ack，或处理失败却没 nack/reject，会导致库存“已扣未记”或“重复扣减”。
- 务必关闭自动确认：
$channel->basic_qos(null, 1, null)+$channel->basic_consume(..., false) - 业务逻辑必须包裹在 try/catch 内，成功才
$msg->ack()，失败则$msg->nack(['requeue' => false])进死信队列 - 扣减库存操作要和数据库事务对齐：先
SELECT ... FOR UPDATE加行锁，再更新，最后发消息；避免先发消息再查库导致超卖 - 心跳必须设：
'heartbeat' => 30，否则云服务器 NAT 网关 60 秒空闲后会静默断连，消费者卡死无日志
最易被忽略的是绑定动作本身——它既不发生在配置文件里，也不在管理后台生效，必须在消费者初始化阶段用代码显式执行。哪怕你用 Docker 跑了 10 个消费者实例，只要有一个没调 queue_bind，那个店铺的库存更新就永远收不到消息。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
