PHP分布式同步需应用层兜底，核心是本地消息表+事务一致性、RabbitMQ死信重试、数据层幂等设计、结构化日志与延迟基线监控。
PHP本身没有分布式任务框架，所谓“多节点同步”必须靠应用层设计来兜底——不是选个框架就能自动同步，而是你得明确每一步谁负责、怎么判重、失败后找谁补。
本地消息表 + 定时扫描是 PHP 最可控的同步起点
跨节点任务触发不能靠 file_put_contents 或临时文件，必须落库。本地消息表要和业务操作共用同一个 PDO 实例、同一事务，否则一提交一丢消息就断链。
关键点：
- 表结构必须含
status字段（pending/sending/sent/failed），不能只靠行存在与否判断 - 扫描 SQL 必须带时间偏移：例如
WHERE status = 'pending' AND created_at ，防刚插入就被捞走 - 状态更新必须原子：
UPDATE local_message SET status = 'sending', updated_at = NOW() WHERE id = ? AND status = 'pending'，只在影响行数为 1 时才真正投递 - 单次扫描最多处理 100 条，避免锁表；扫描间隔设为 2 秒，太短压 DB，太长拖补偿
RabbitMQ 投递不等于消息已入队，PHP 客户端默认不保可靠
basic_publish() 返回成功 ≠ 消息进了 RabbitMQ。没开 confirm 模式，网络抖动或 broker 瞬间不可用，消息就静默丢失了。
立即学习“PHP免费学习笔记（深入）”；
必须显式启用并等待确认：
- 创建 channel 后立即调用
$channel->confirm_select() - 发完消息必须调用
$channel->wait_for_pending_acks()，超时未确认即视为失败 - 队列声明时加死信参数：
'x-dead-letter-exchange' => 'dlx.task'和'x-dead-letter-routing-key' => 'retry.sync' - 死信交换器类型只能是
direct或topic，不能是fanout；若需延迟重试，得配好 TTL + 死信转发链
多节点消费同一条消息时，幂等性不是可选项，是生死线
消息被多个消费者同时拉取、重复执行，是常态。靠“只让一个节点运行脚本”这种运维手段，既不可靠也难监控。
真正的幂等要落在数据层：
- 写数据库用
INSERT ... ON DUPLICATE KEY UPDATE，但仅限主键/唯一键冲突场景；字段超长、触发器报错等不会触发ON DUPLICATE，得靠try/catch捕获具体异常码 - 更新操作前先查当前状态：
UPDATE task_log SET status = 'done' WHERE task_id = ? AND status = 'processing'，影响行为 0 表示已被别人处理过 - 用 Redis 做指纹缓存时，key 要包含业务上下文全量（如
sync:order:12345:stock_deduct），过期时间设为任务最大执行时间的 2 倍 - 不要用
SELECT FOR UPDATE锁整张表，锁粒度大、易阻塞；优先用带条件的UPDATE做乐观锁
最终一致性 ≠ 放任不一致，必须有可验证的收敛机制
“数据最终会一致”这句话只有配上监控和修复能力才有意义。没人盯日志、没人跑校验脚本、没人配置告警，那“最终”可能就是“永不”。
至少做到三件事：
- 每条同步任务记录
source_id、target_id、sync_time、error_msg，便于按 trace_id 追踪全链路 - 每天凌晨跑一次数据比对脚本，抽样比对关键字段（如订单金额、库存余量），差异写入
consistency_alert表 - 提供手动触发补偿的 CLI 命令：
php bin/sync-retry.php --task-id=789 --max-attempts=3，而不是只能等定时任务 - 所有同步动作必须输出结构化日志（JSON 格式），含
trace_id、step、duration_ms、result，方便接入 ELK 或 Loki
最常被忽略的是：同步延迟本身会掩盖问题。比如从库延迟 3 秒，你查目标库发现数据没到，第一反应是“同步失败”，其实只是慢了。得先确认延迟基线，再判断是否真故障。
