在分布式程序里最让人头疼的莫过于“消息丢失”——无论是使用者崩溃、网络抖动还是双写失配，都可能导致业务数据和事件不同步。下面以 DeepFlux 的 outbox 模式为例。拆解完整的解决思路，并针对常见痛点给出实用对策。

在 Outbox 场景里“消息”就是一行数据库记录。说到它携带了，

• event_id – 唯一标识
• event_type – 事件类型。如 agent.session.completed
• aggregate_id – 发生在哪个聚合上
• payload
• published_at – NULL 表示待处理，非 NULL 表示已处理

这条记录既是业务写入的一部分，也是未来被消费的“信件”。将它放进表而不是立即推送到 Kafka，可彻底避免双写问题。

二、解决“双写”难题：事务 Outbox 是主要武器

"先写库再发" 与 "先发再写库" 两种做法都可能只成功一半。Outbox 把两者合并为同一个事务：

BEGIN;INSERT INTO events_outbox VALUES;-- 写入业务 + 消息
INSERT INTO or_table VALUES;-- 同一事务里的其他业务写
COMMIT;

如果事务回滚，既没有业务变更也没有消息被发布;如果提交成功，数据库里的两条记录都完整出现。后续后台进程会统一读取并转发。

三、谁来取？为何不直接用消息队列，

Pain Point：担心引入 NATS/Kafka 成本高、运维繁琐。话说回来，

DPP明确把“无订阅者的总线是纯运维负担”视作风险。采用直接轮询数据库表,不需要额外集群或死信队列。只要 Postgres 高可用，这一步就稳如磐石。

四、抢单安全：FOR UPDATE SKIP LOCKED & 并发分账实验结果

Pain Point：多使用者同时抢同一批消息会否出现重复或阻塞？

SELECT * FROM events_outbox
WHERE published_at IS NULL
AND event_type = ANY
ORDER BY occurred_at
LIMIT 1000
FOR UPDATE SKIP LOCKED;-- A & B 同时执行，只会得到互不重叠的数据行。

"SKIP LOCKED" 确保已被锁定的行不会被其它 worker 拿到；若某个 consumer 崩溃，未提交的事务会自动回滚。行重新变为待处理状态——保证了至少一次交付且无数据丢失。

五、至少一次交付 & 消费端幂等性保障

- 当 consumer 在认领与标记之间崩溃时行返回待处理； 下一轮 被消费，

- 标记操作采用 `UPDATE events_outbox SET published_at = now WHERE id = ANY`，若已被标记则无效。结合 `upsert` 的 “存在则累加。不存在则插入”，即使同一事件被多次消费，也保持最终一致。

六、坏事件如何不堵住好事件？失败表 + SEPOINT 策略

• 按使用者隔离失败表：`contenthub_failures` 用来记录解析错误及下次重试时间；主查询通过 `LEFT JOIN` 跳过尚未到期的坏事件。
• SEPOINT + 单条错误隔离：`SEPOINT sp_i;INSERT INTO usage_metrics;老实说，ROLLBACK TO sp_i;` — 单条失败不会影响整批提交。按理说，
• 多使用者互不干扰：`event_type` 做过滤。每个 consumer 专门挑自己关心的类型即可；不过，只要类型不冲突，就不存在竞争。

七、CronJob：兜底任务防止“时间债务”堆积

• hitl-timeout：每分钟扫描 “等待审批且已超时”的会话，一键拒绝并触发与人工拒绝相同逻辑；避免使用者关闭浏览器后永远停留在等待状态。
• 其他 CronJob：- 每日创建审计分区 - 每周淘汰旧内存 - 每月重置配额 - 每分钟更新积分

CronJob 可以直接访问数据库。但跨 娱乐 的数据只能通过暴露的 API 而非裸 SQL，以遵循 D‑Rule #4：“跨 娱乐 数据必须走应用层接口”。这既降低安全风险，又兼顾性能。按理说，

八、小结 & 实战建议

1. DPP 中 Outbox 能彻底消除双写风险。只需保证一次事务就可以完成所有业务+消息写入。