你的數(shù)據(jù)管道每天凌晨自動(dòng)運(yùn)行。某天它跑到80%時(shí)崩潰了，系統(tǒng)自動(dòng)重試——然后你的數(shù)據(jù)庫里多了8000條重復(fù)記錄。沒有報(bào)錯(cuò)，沒有告警，業(yè)務(wù)報(bào)表卻開始失真。這不是假設(shè)，是數(shù)據(jù)集成中最常見的沉默故障模式。

這個(gè)問題有個(gè)專業(yè)術(shù)語：冪等性（idempotency）。簡(jiǎn)單說，一個(gè)操作執(zhí)行一次和執(zhí)行多次，結(jié)果應(yīng)該完全相同。但在實(shí)際工程中，大多數(shù)管道最初都是非冪等的——插入比更新合并簡(jiǎn)單，重復(fù)問題只在重試時(shí)才暴露。

三種典型場(chǎng)景會(huì)觸發(fā)重復(fù)寫入。第一是部分成功后的重試：處理了8000條后失敗，重試時(shí)從頭開始，已寫入的8000條被再次處理。第二是并行執(zhí)行沖突：云調(diào)度器發(fā)現(xiàn)任務(wù)卡住，啟動(dòng)新實(shí)例時(shí)舊實(shí)例仍在運(yùn)行，兩者同時(shí)向同一目標(biāo)寫入同一批數(shù)據(jù)。第三是檢查點(diǎn)失效：進(jìn)度標(biāo)記在寫入后、確認(rèn)前崩潰，下次運(yùn)行時(shí)會(huì)重復(fù)加載已處理的數(shù)據(jù)。

存儲(chǔ)層最可靠的解決方案是upsert操作：記錄不存在則插入，存在則更新。PostgreSQL中用INSERT ... ON CONFLICT DO UPDATE，SQL Server和Oracle中用MERGE。關(guān)鍵在于每條記錄必須有穩(wěn)定的唯一標(biāo)識(shí)——來源系統(tǒng)提供的自然鍵，或從記錄內(nèi)容確定性生成的哈希值。

實(shí)現(xiàn)冪等性并不復(fù)雜，但它要求你在搭建管道時(shí)就明確做出狀態(tài)管理決策。而這個(gè)決策，恰恰最容易被初期的"先跑起來再說"心態(tài)跳過。