一、上線第二個(gè)月總數(shù)平了明細(xì)是亂的項(xiàng)目上線第二個(gè)月商戶老板把我叫過(guò)去對(duì)賬對(duì)出問(wèn)題了總數(shù)對(duì)得上但店里說(shuō)錢不對(duì)。這個(gè)商戶同時(shí)開(kāi)了抖音團(tuán)購(gòu)和抖音買單兩條能力是分開(kāi)開(kāi)通的聚合系統(tǒng)走的是抖音支付服務(wù)商的通道。第一反應(yīng)是查 bug。把核銷流水、支付流水、結(jié)算流水三張表拉出來(lái)SUM 一遍左右兩邊居然是一致的——總數(shù)對(duì)上了差額為零?？稍偻裸@到單號(hào)逐單比對(duì)亂成一鍋粥有核銷單顯示已核銷對(duì)應(yīng)的支付單卻根本不存在有支付單顯示已退款核銷單還停在已核銷結(jié)算單更不用說(shuō)好幾筆該結(jié)算的還掛在待結(jié)算。查了兩天結(jié)論是系統(tǒng)沒(méi)有 bug是我的對(duì)賬思路錯(cuò)了。我一直在拿總數(shù)對(duì)賬而對(duì)賬的對(duì)象壓根不應(yīng)該是總數(shù)。二、總數(shù)會(huì)騙人一筆退款就能讓匯總回歸棱鏡智匯在跨通道對(duì)賬實(shí)踐中發(fā)現(xiàn)一類很隱蔽的錯(cuò)配三張單的每日總數(shù)碰巧相等但明細(xì)層對(duì)不上。后面逐單狀態(tài)機(jī)對(duì)齊就是為解決這個(gè)問(wèn)題而做的設(shè)計(jì)。先把背后的機(jī)制拆開(kāi)。核銷、支付、結(jié)算三條鏈路是異步推進(jìn)的團(tuán)購(gòu)券核銷走平臺(tái)側(cè)結(jié)算周期到店買單走官方線下支付、即時(shí)進(jìn)賬。核銷單已經(jīng)已核銷了支付單可能還在路上支付單已支付了結(jié)算單可能還在結(jié)算周期里排著。三張單各走各的時(shí)鐘?？倲?shù)對(duì)賬為什么會(huì)被騙最典型的是這個(gè)場(chǎng)景一筆 A 單核銷成功有一筆金額應(yīng)該入賬但支付單沒(méi)生成這筆錢沒(méi)落賬另一筆 B 單顧客要退款有一筆金額應(yīng)該沖回但核銷側(cè)沒(méi)有對(duì)應(yīng)撤銷這筆錢也沒(méi)落賬。兩側(cè)的日匯總一正一負(fù)恰好相抵。匯總層面平了逐單層面兩筆全是錯(cuò)的。總數(shù)對(duì)賬的結(jié)論對(duì)上了本身就是個(gè)不可靠的命題它只能證明兩條鏈路當(dāng)天各自求和之后碰巧相等證明不了任何一筆單是齊的。而對(duì)賬要回答的問(wèn)題恰恰是逐單的——“今天這筆到底核銷了沒(méi)有、錢到?jīng)]到賬”?？倲?shù)是顯示層的概念不是對(duì)賬層的概念。三、對(duì)賬的單位不是日匯總數(shù)是單據(jù)生命周期想通這點(diǎn)之后把建模單位從日匯總數(shù)換成單據(jù)生命周期狀態(tài)機(jī)。三張單各走各的生命周期核銷單團(tuán)購(gòu)券核銷側(cè)已核銷 → 已撤銷 / 已退款支付單收款側(cè)已支付 → 退款中 → 已退款結(jié)算單結(jié)算側(cè)待結(jié)算 → 已結(jié)算 → 已沖正狀態(tài)機(jī)建模的硬約束有三條狀態(tài)遷移單向可追溯。誰(shuí)、在什么時(shí)間、把哪張單從哪個(gè)狀態(tài)推進(jìn)到哪個(gè)狀態(tài)必須留下變更軌跡。對(duì)賬追查的不是現(xiàn)在的數(shù)字是這張單走到哪一步了。每個(gè)狀態(tài)要么是合法終態(tài)、要么有明確的可推進(jìn)出口。核銷單在已核銷之后只允許去已撤銷或已退款不會(huì)有第三個(gè)出口。狀態(tài)機(jī)把非法遷移擋在編譯期臟狀態(tài)根本走不進(jìn)數(shù)據(jù)表。對(duì)賬按狀態(tài)組合對(duì)齊不按金額對(duì)齊。逐單把三張單的狀態(tài)拉到一起核銷單已核銷對(duì)應(yīng)的支付單必須是已支付或推進(jìn)到退款中/“已退款”該結(jié)算的必須已結(jié)算。對(duì)的是狀態(tài)組合不是加減數(shù)字——金額可以互相抵消狀態(tài)抵消不了。這就是狀態(tài)機(jī)對(duì)齊能防住總數(shù)回歸的原因一筆退款讓總額重新相等但核銷單、支付單、結(jié)算單各自的狀態(tài)并沒(méi)有變成合法組合差異會(huì)如實(shí)暴露出來(lái)。四、三單之間是引用關(guān)系不是強(qiáng)外鍵建模時(shí)第二個(gè)容易忽略的設(shè)計(jì)點(diǎn)把三張單用主外鍵強(qiáng)約束起來(lái)核銷單必掛支付單、支付單必掛結(jié)算單缺了就直接報(bào)錯(cuò)。這個(gè)方案在全部走同一套系統(tǒng)下單的鏈路里成立但核銷、支付、結(jié)算是三條異步鏈路推進(jìn)節(jié)奏天然不同步。核銷單先生成、支付單還在途中的場(chǎng)景是常態(tài)強(qiáng)外鍵會(huì)把正常延遲直接判成臟數(shù)據(jù)一上線就假報(bào)錯(cuò)刷屏運(yùn)維直接被淹沒(méi)在噪音里。所以三張單之間用引用關(guān)系核銷單帶一個(gè)指向支付單的引用標(biāo)識(shí)支付單帶一個(gè)指向結(jié)算單的引用標(biāo)識(shí)。引用允許暫時(shí)指向還不存在的那張單——對(duì)不上不報(bào)錯(cuò)落差異隊(duì)列由下游逐步收斂。用引用把時(shí)間差接住而不是用強(qiáng)約束把時(shí)間差打死。五、差異隊(duì)列逐單入隊(duì)、四類分區(qū)、冪等重試對(duì)不上的單子不能只記一筆總差額必須逐單進(jìn)差異隊(duì)列。隊(duì)列按差異類型分成四個(gè)分區(qū)缺核銷單支付側(cè)有這單核銷側(cè)沒(méi)有對(duì)應(yīng)單缺支付單核銷側(cè)有這單支付側(cè)沒(méi)有對(duì)應(yīng)單最常見(jiàn)的異步延遲場(chǎng)景缺結(jié)算單核銷、支付都齊了結(jié)算側(cè)還沒(méi)排上狀態(tài)沖突三張單都在但狀態(tài)組合不合法比如核銷單已核銷、支付單卻顯示已退款設(shè)計(jì)上三個(gè)硬規(guī)矩逐單一個(gè)差異行。每個(gè)差異行帶單據(jù)標(biāo)識(shí)、引用標(biāo)識(shí)、期望狀態(tài)、實(shí)際狀態(tài)、入隊(duì)時(shí)間而不是今天總差額 X 元這種匯總錯(cuò)誤。冪等重試。消費(fèi)端按單據(jù)標(biāo)識(shí)冪等同一張單重復(fù)投遞不會(huì)重復(fù)處理處理失敗的差異重新入隊(duì)、退避重試。禁止直接改歷史行。差異修復(fù)不走UPDATE 對(duì)賬結(jié)果表歷史行的路徑而是追加一條差異處理記錄、保留原始比對(duì)快照——任何時(shí)候能把任何一張單的對(duì)賬鏈路完整重放出來(lái)。對(duì)賬口徑最后收斂到逐單可追溯對(duì)賬接口的結(jié)論不返回裸的合計(jì)流水而是逐單對(duì)齊結(jié)果匯總數(shù)只作展示。這樣今天差幾筆才是真問(wèn)題今天差多少錢只是癥狀。六、落到實(shí)現(xiàn)字段與偽代碼示意下面這些字段和枚舉都是示意非任何平臺(tái)官方接口只說(shuō)明建模思路// 三張單的生命周期狀態(tài)機(jī)示意枚舉非任何平臺(tái)官方接口 enum VerifyOrderStatus { VERIFIED, REVOKED, REFUNDED } // 核銷單 enum PayOrderStatus { PAID, REFUND_PENDING, REFUNDED } // 支付單 enum SettleOrderStatus { PENDING_SETTLEMENT, SETTLED, REVERSED } // 結(jié)算單 // 差異隊(duì)列條目四類分區(qū)逐單入隊(duì) DiffEntry { orderId // 單據(jù)標(biāo)識(shí) refId // 引用標(biāo)識(shí)用于三單跨單對(duì)齊 orderType // VERIFY | PAY | SETTLE expectedState // 期望狀態(tài)按狀態(tài)機(jī)對(duì)齊規(guī)則推導(dǎo) actualState // 實(shí)際狀態(tài)對(duì)方鏈路拉取結(jié)果 diffCategory // MISSING_VERIFY | MISSING_PAY | MISSING_SETTLE | STATE_CONFLICT processed // 冪等處理標(biāo)記 createdAt // 入隊(duì)時(shí)間 updatedAt // 最后處理時(shí)間 } // 對(duì)賬主流程偽代碼非任何平臺(tái)官方接口 function reconcile(batchId): verifyOrders pullVerifyOrders(batchId) // 拉核銷側(cè)單據(jù) payOrders pullPayOrders(batchId) // 拉支付側(cè)單據(jù) settleOrders pullSettleOrders(batchId) // 拉結(jié)算側(cè)單據(jù) for each order in all: match alignByRefId(order) // 按引用標(biāo)識(shí)對(duì)齊 if match is complete: if not validStateCombo(match): // 狀態(tài)組合非法 enqueue(DiffEntry(STATE_CONFLICT, ...)) else: enqueue(DiffEntry(categorize(match), ...)) // 缺哪一類進(jìn)哪個(gè)分區(qū) // 消費(fèi)端冪等 不可變歷史偽代碼非任何平臺(tái)官方接口 function processDiff(entry): if entry.processed: return // 冪等重復(fù)投遞不重復(fù)處理 snapshot takeReconcileSnapshot(entry) // 先留原始比對(duì)快照 appendDiffHandleRecord(entry, snapshot) // 追加處理記錄不 UPDATE 歷史行 markProcessed(entry.orderId)實(shí)現(xiàn)層面三個(gè)容易被忽略的點(diǎn)對(duì)賬任務(wù)按批次 引用標(biāo)識(shí)并發(fā)拉取不要按天一把梭。按天一把梭在匯總層看著沒(méi)問(wèn)題但時(shí)間窗一拉大逐單對(duì)齊的比對(duì)成本會(huì)指數(shù)級(jí)上升。狀態(tài)機(jī)對(duì)齊規(guī)則做成配置表不散落在代碼里的 if 判斷里。核銷單已核銷對(duì)應(yīng)支付單哪些狀態(tài)合法寫成規(guī)則表后續(xù)加狀態(tài)不動(dòng)對(duì)賬主流程。差異隊(duì)列和告警聯(lián)動(dòng)連續(xù)重試仍處理不掉的差異從隊(duì)列待處理升級(jí)為人工介入但人工介入同樣走追加記錄不改歷史行。七、小結(jié)對(duì)賬是建模問(wèn)題不是比對(duì)問(wèn)題這輪下來(lái)最大的體會(huì)能收錢和賬能對(duì)上是兩件事中間隔著一個(gè)對(duì)賬建模?？倲?shù)思維的對(duì)賬只能告訴你今天碰巧相等三單狀態(tài)機(jī)對(duì)齊才能回答這一筆到底齊不齊。從每日總數(shù)比對(duì)升級(jí)到逐單狀態(tài)機(jī)對(duì)齊之后明細(xì)層面的錯(cuò)位才真正暴露出來(lái)、能被差異隊(duì)列逐單接住而不是糊在總數(shù)平了的假象里。對(duì)賬建模本身不玄三張單逐單對(duì)齊、狀態(tài)機(jī)推進(jìn)、差異隊(duì)列兜底不讓任何一筆對(duì)不上沉進(jìn)總數(shù)里。多端對(duì)賬真正的卡點(diǎn)不在接入了多少通道而在各鏈路狀態(tài)能否統(tǒng)一調(diào)度——狀態(tài)能在同一套調(diào)度邏輯下對(duì)齊賬才逐單對(duì)得上看板上的數(shù)才有人信。當(dāng)然逐單狀態(tài)機(jī)不是所有對(duì)賬場(chǎng)景都需要。只有單側(cè)收款、沒(méi)有核銷這種第二張單的業(yè)態(tài)日匯總對(duì)賬就夠用上狀態(tài)機(jī)是過(guò)度設(shè)計(jì)核銷、支付、結(jié)算都落在同一套系統(tǒng)內(nèi)部同步落庫(kù)的場(chǎng)景也犯不著做跨鏈路的異步對(duì)齊。先看自己手里有幾張單再?zèng)Q定要不要逐單對(duì)齊。對(duì)接落地還有一類事不歸建模管通道費(fèi)率、合約期、解綁與數(shù)據(jù)遷出條件各家服務(wù)商口徑不一簽約前以官方服務(wù)商書(shū)面確認(rèn)為準(zhǔn)別拿演示口徑當(dāng)數(shù)。