php不支持原生跨库分布式事务，需通过应用层设计实现最终一致性：①本地消息表+定时任务；②可靠mq+幂等消费；③简化tcc模式；④优先重构规避分布式事务。
PHP本身不支持跨服务的分布式事务，所谓“PHP实现分布式事务”，实际是用PHP落地最终一致性方案——核心不是让事务变强，而是让不一致可发现、可补偿、可收敛。
本地消息表为什么必须和业务操作同库同事务
这是保障“业务写入”和“消息落库”原子性的唯一低成本方式。如果消息表在另一个数据库，或用异步写入（比如先 commit 再发 MQ），就必然出现 order 创建成功但 inventory.deduct 消息丢失的情况。
- 必须用同一
$db连接实例，不能是两个独立 PDO 对象 -
LocalMessage::save()调用必须在$db->commit()之前，且共享同一事务上下文 - 表结构里要有
status字段（pending/sending/sent/failed），不能只靠存在与否判断 - 不要用
INSERT ... ON DUPLICATE KEY UPDATE替代事务，它无法捕获主键冲突外的其他失败（如字段超长、触发器报错）
定时扫描任务怎么避免重复投递和漏扫
扫描不是简单 SELECT * FROM local_message WHERE status = 'pending'，关键在条件和更新逻辑。
- 扫描 SQL 必须带时间窗口：例如
WHERE status = 'pending' AND created_at ，防止刚插入的消息被立刻捞走（时钟不同步或事务延迟） - 更新状态要用原子语句：
UPDATE local_message SET status = 'sending', updated_at = NOW() WHERE id = ? AND status = 'pending'，返回影响行数为 1 才真正投递 - 投递成功后，再执行一次
UPDATE ... SET status = 'sent'；失败则设为failed并记录last_error - 扫描间隔建议 1–3 秒，太短增加 DB 压力，太长导致补偿延迟；单次最多处理 100 条，防锁表
RabbitMQ publisher confirm + 死信队列怎么配才不丢消息
PHP 客户端（如 php-amqplib）默认不开启可靠投递，需显式配置，否则 channel->basic_publish() 返回成功 ≠ 消息进队列。
- 创建 channel 后必须调用
$channel->confirm_select() - 发送后要等
$channel->wait_for_pending_acks()或监听wait回调，超时未确认即视为失败 - 队列声明时设置
arguments：['x-dead-letter-exchange' => 'dlx.inventory', 'x-dead-letter-routing-key' => 'retry.deduct'] - 死信队列绑定的交换器必须是
topic或direct类型，并配好延迟插件（x-delayed-type）或 TTL + 死信转发链
消费端幂等为什么不能只靠 order_id 做唯一索引
单一业务 ID 在重试、乱序、跨分区场景下不足以保证幂等，必须引入事件维度。
- 判重表需包含
(order_id, event_id)联合唯一索引，其中event_id是消息中间件生成的全局唯一 ID（如 RabbitMQ 的message_id或 Kafka 的offset+partition） - 不要用时间戳或自增 ID 当
event_id，它们不具备跨节点唯一性 - 插入判重记录必须和业务更新在同一事务内，否则可能“判重成功但业务失败”，下次重试又被放过
- 若用 Redis 实现判重，
SETNX key value EX 3600后必须校验 value 是否匹配，防误删（Redis 集群 key slot 不一致时易出问题）
最易被忽略的是补偿动作本身的可靠性：比如扣减库存失败后发的 RestoreInventory 补偿指令，它自己也得走一遍本地消息表+扫描+幂等消费闭环，否则就变成“用一个不可靠机制修复另一个不可靠机制”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
