PHP不支持原生跨库分布式事务，需通过应用层设计实现最终一致性：①本地消息表+定时任务；②可靠MQ+幂等消费；③简化TCC模式；④优先重构规避分布式事务。
PHP 本身不直接支持跨数据库的分布式事务（如 XA 协议），但可通过应用层设计+数据库能力组合实现最终一致性或类两阶段提交（2PC）语义。核心思路是：**放弃强一致性，用补偿、幂等、状态机和可靠消息来保障业务逻辑的事务性**。
基于本地消息表 + 最终一致性
这是最常用、落地最稳的方案，适用于 MySQL 等支持事务的关系型数据库：
- 在业务库中建一张 msg_log 表，字段包括：全局唯一消息ID、目标服务名、消息内容（JSON）、状态（pending/sent/confirmed/failed）、创建/更新时间
- 主业务操作与插入消息记录在同一个本地事务中提交——保证“业务成功 → 消息必落库”
- 另起一个独立进程（如 Laravel Command / Symfony Console / 纯 PHP CLI 脚本）定时扫描 pending 消息，调用下游服务接口；成功后更新状态为 confirmed，失败则重试 + 限流 + 告警
- 下游服务需提供幂等接口（例如用消息ID做去重键），并自身也支持回滚或反向操作（如“扣库存”对应“补库存”）
使用可靠消息中间件（如 RabbitMQ、RocketMQ、Kafka）
将消息持久化交给专业中间件，解耦应用与事务管理逻辑：
- 业务执行成功后，向 MQ 发送事务消息（RabbitMQ 支持 publisher confirms；RocketMQ 支持半消息 + check 机制）
- PHP 应用监听对应队列，消费消息并执行下游操作；消费成功后手动 ACK，失败则重投（注意设置最大重试次数和死信队列）
- 关键点：下游处理必须幂等；消息体建议含业务单号、操作类型、原始参数快照，便于排查和人工补偿
- 若需反向补偿（如转账失败要退款），可发送另一条“逆向消息”，由同一消费者按类型路由处理
简化版 TCC（Try-Confirm-Cancel）模式
适合对一致性要求高、且能改造上下游服务的场景。PHP 中可借助状态机库（如 yohang/finite）管理流程：
立即学习“PHP免费学习笔记（深入）”；
- Try 阶段：预留资源（如冻结账户余额、预占库存），写入业务状态为 try_success，不真正扣减
- Confirm 阶段：确认执行（真正扣减），仅当所有 Try 成功才触发；失败则统一走 Cancel
- Cancel 阶段：释放预留资源（解冻、释放库存）
- PHP 层需维护全局事务 ID 和各分支事务状态，配合定时任务扫表驱动未完成流程，避免悬挂或空转
规避分布式事务的替代设计
很多时候，重构比硬上分布式事务更高效：
- 把跨库操作合并到同一数据库（垂直/水平分库前先评估是否真需要）
- 用冗余字段+异步同步代替实时关联查询（如订单表存用户昵称，后台定时刷新）
- 将强一致操作改为用户可感知的“分步提交”（如下单→支付→发货，每步独立事务，失败可提示重试）
- 核心资金类操作尽量收口到单一服务（如统一账户中心），其他服务只调用其 API
