# Goldsky Turbo重复投递如何核？分checkpoint、落地主键与重组修正

整理：链小知（AI 辅助）
资料核对日期：2026-10-14
引用地址：https://lianxiaozhi.com/tools/guides/goldsky-turbo-delivery-dedup-reorg-sink-check
难度：进阶
核验方式：官方文档整理，未执行真实账户操作

从已有管线与接收材料检查重复是否被安全处理，不把200回执或主键配置当完整准确一次。

## 使用工具
- [Goldsky](https://lianxiaozhi.com/tools/goldsky) · [官方入口](https://goldsky.com/)

## 前置条件
- 准备自己已有的脱敏配置、日志或状态回执，保留产品版本、对象、字段和日期；缺值不补成成功或零。

## 1. 固定Turbo输入和接收对象

记录管线、source→transform→sink路径、数据集版本、接收表或endpoint和primary_key。Turbo与legacy Mirror、subgraph、Feeds属于不同入口；本篇按Turbo当前投递契约解释。沿每个transform保留稳定记录键，缺原schema/key时不臆造transaction hash唯一性或删除事件编码。

核对结果：产品、管线路径、接收对象和稳定键有记录；未知schema保持待核。
依据：[Goldsky：Turbo来源、转换与落地](https://docs.goldsky.com/turbo-pipelines/introduction.md)
依据：[Goldsky：至少一次投递、checkpoint和重组修正](https://docs.goldsky.com/turbo-pipelines/delivery-guarantees.md)

## 2. 定位写成功到offset提交的重复窗口

官方至少一次协议先让每个sink flush并ACK同一epoch，全部ACK后再finalizer通知source提交位置。崩溃若发生在落地成功与source提交之间，重启会重放上次已提交位置之后的数据；已写批次的网络重试也可能重复。epoch是checkpoint序号，不是链上事件ID，不能替稳定记录键。

核对结果：重复位置与提交阶段对齐；没有把源offset、epoch和业务记录ID当同一个对象。
依据：[Goldsky：至少一次投递、checkpoint和重组修正](https://docs.goldsky.com/turbo-pipelines/delivery-guarantees.md)

## 3. Postgres有主键才是upsert

sink.primary_key可为逗号分隔列；设置后默认on_conflict=update，无主键是普通INSERT。on_conflict=nothing仅忽略冲突，不会更新；update_where把每列EXCLUDED与现表比较并用AND合成条件，只在update模式生效，nothing会忽略。按原配置核是否允许预期更正；已有表不会自动ALTER新增列，schema变化可能在插入时报错，不能将写失败当无事件。

核对结果：主键、冲突模式和更新条件分别明确；重组更正与schema失败没有被静默跳过。
依据：[Goldsky：Postgres主键、条件更新与schema变化](https://docs.goldsky.com/turbo-pipelines/sinks/postgres.md)
依据：[Goldsky：至少一次投递、checkpoint和重组修正](https://docs.goldsky.com/turbo-pipelines/delivery-guarantees.md)

## 4. Webhook回执与接收幂等分开

one_row_per_request=true为单对象，false默认批次数组；batch_size默认1000、batch_flush_interval默认1s是flush控制，不是engine checkpoint间隔。2xx确认批次；网络/超时、408、429与5xx无限指数退避，其他4xx立即失败管线。primary_key用于checkpoint/旁路跟踪，不替接收端去重；接收程序须按稳定键去重或让副作用幂等，不能把重试后2xx当只执行了一次。

核对结果：对象/数组、HTTP分支、flush与checkpoint已区分；副作用去重有证据或未知。
依据：[Goldsky：Webhook批次、响应与重试](https://docs.goldsky.com/turbo-pipelines/sinks/webhook.md)
依据：[Goldsky：至少一次投递、checkpoint和重组修正](https://docs.goldsky.com/turbo-pipelines/delivery-guarantees.md)

## 5. 把重复处理与重组修正分别验收

重组导致的delete/update沿管线传播；支持主键的数据库sink将其应用为upsert/delete，append-only的Kafka/S3/webhook须由消费者应用修正。恢复后不保证重启前后顺序，去重不能简单忽略同键全部后续更正。缺实际修正payload/消费结果时只确认官方路径，不能推canonical状态已收敛；Postgres聚合sink跨epoch重投不去重，也不能套普通表效果。计量中的创建、更新、删除均算写入，写入数不等独立链上事件数。

核对结果：重复幂等、delete/update、顺序与最终状态各有结果或缺项；未把写入计量当事件数。
依据：[Goldsky：至少一次投递、checkpoint和重组修正](https://docs.goldsky.com/turbo-pipelines/delivery-guarantees.md)
依据：[Goldsky：Postgres主键、条件更新与schema变化](https://docs.goldsky.com/turbo-pipelines/sinks/postgres.md)
依据：[Goldsky：Starter一次额度、Scale计量与托管数据库](https://docs.goldsky.com/pricing/summary.md)

## 常见错误
- 至少一次加幂等目的地才可能达到effectively exactly-once结果；平台没有一个开关替不幂等接收端解决问题。
- checkpoint不持久化中间transform内存状态，重启重放重新派生；链上最终性与投递协议是不同判断。

## 完成检查
- 形成输入、官方判定方法、已知结果和未知分支的对照；方法已核，实际运行与本人权限未验证。

## 相关知识

## 官方依据
- [Goldsky：Turbo来源、转换与落地](https://docs.goldsky.com/turbo-pipelines/introduction.md)
- [Goldsky：至少一次投递、checkpoint和重组修正](https://docs.goldsky.com/turbo-pipelines/delivery-guarantees.md)
- [Goldsky：Postgres主键、条件更新与schema变化](https://docs.goldsky.com/turbo-pipelines/sinks/postgres.md)
- [Goldsky：Webhook批次、响应与重试](https://docs.goldsky.com/turbo-pipelines/sinks/webhook.md)
- [Goldsky：Starter一次额度、Scale计量与托管数据库](https://docs.goldsky.com/pricing/summary.md)