2023年某支付平臺故障，用戶余額憑空多出一個(gè)零。工程師排查了72小時(shí)，最終發(fā)現(xiàn)是一行UPDATE語句在并發(fā)時(shí)撞上了 race condition（競態(tài)條件）。錢從哪來？到哪去？沒人說得清。

這種事故在金融科技領(lǐng)域不算新聞。單字段存余額的設(shè)計(jì)，就像把現(xiàn)金鎖在抽屜里卻不記賬——抽屜一亂，全盤皆輸。

Paul Babatuyi 在 GitHub 開源的 double-entry-bank 項(xiàng)目，用 Go 和 PostgreSQL 演示了另一種思路：雙分錄記賬。每筆交易生成兩條記錄，一借一貸，相互勾稽。沒有 UPDATE，只有 INSERT；沒有刪除，只有追加。賬本變成只讀的歷史流，任何異常都能被追溯。

為什么單字段余額是定時(shí)炸彈

開發(fā)者常犯的錯(cuò)，是把"余額"當(dāng)成一個(gè)可以隨便改的數(shù)字。UPDATE accounts SET balance = balance - 100 看起來無害，實(shí)則埋了三顆雷。

第一顆是原子性。 兩條并發(fā)請求同時(shí)讀取余額1000，各自減去100，最終寫入900。實(shí)際應(yīng)該扣200，系統(tǒng)卻只扣了100。這種"丟失更新"在流量高峰時(shí)幾乎必然發(fā)生。

第二顆是可審計(jì)性。 余額字段被覆蓋后，舊值永久消失。用戶投訴"錢少了"，你只能看到當(dāng)前數(shù)字，無法還原變化路徑。監(jiān)管合規(guī)？更是無從談起。

第三顆是人為風(fēng)險(xiǎn)。 擁有 UPDATE 權(quán)限的工程師，理論上可以靜默修改任意賬戶。沒有日志交叉驗(yàn)證，內(nèi)部舞弊難以被發(fā)現(xiàn)。

雙分錄記賬的解法很古老——1494年盧卡·帕喬利在《算術(shù)、幾何、比及比例概要》中系統(tǒng)闡述的復(fù)式記賬，至今仍是現(xiàn)代金融的基石。每一筆資金流動必須同時(shí)記錄來源和去向，總額恒等。

7張表如何鎖住每一分錢

Paul 的數(shù)據(jù)庫設(shè)計(jì)沒有魔法，只是把"余額"這個(gè)概念拆解成了不可變的事件流。

核心表只有三張：accounts（賬戶定義）、entries（分錄明細(xì)）、transfers（交易主檔）。accounts 記錄賬戶類型和幣種，余額不存這里。entries 是真正的賬本，每條記錄包含賬戶ID、金額、借貸方向，以及指向 transfers 的外鍵。transfers 則保存交易元數(shù)據(jù)：發(fā)起方、接收方、時(shí)間戳、外部流水號。

查詢余額時(shí)，不再是 SELECT balance FROM accounts，而是 SUM(entries.amount) WHERE account_id = X。實(shí)時(shí)計(jì)算聽起來費(fèi)性能？PostgreSQL 的索引和物化視圖能搞定，或者像 Stripe 那樣異步匯總到緩存——但緩存只是只讀副本，真相永遠(yuǎn)在 entries 表里。

另外四張表處理支撐功能：users、sessions、verify_emails 管身份，還有一張參數(shù)表存配置。業(yè)務(wù)表與支撐表隔離，權(quán)限粒度可以收得很細(xì)。

sqlc 把 SQL 變成類型安全的 Go 代碼

手寫數(shù)據(jù)庫操作容易出錯(cuò)。字段名拼錯(cuò)、類型對不上、NULL 處理遺漏——這些 bug 在編譯期發(fā)現(xiàn)不了，上線后才炸。

sqlc 的解決思路是反向生成：你先寫 SQL 查詢，它自動生成對應(yīng)的 Go 結(jié)構(gòu)和接口。查詢文件放在 postgres/queries/ 目錄，sqlc.yaml 配置好連接信息，執(zhí)行 sqlc generate 就能得到 db.go、models.go、querier.go 三個(gè)文件。

好處是 SQL 和 Go 的類型系統(tǒng)打通。你在查詢里寫 SELECT id, owner, balance FROM accounts，生成的代碼就返回包含這三個(gè)字段的結(jié)構(gòu)體。改表結(jié)構(gòu)？改 SQL 文件重新生成，編譯錯(cuò)誤會精準(zhǔn)定位到所有受影響的地方。

Paul 的遷移文件用 golang-migrate 管理，版本號順序執(zhí)行，回滾也有對應(yīng)腳本。這套組合讓數(shù)據(jù)庫變更可 review、可回滾、可追蹤——和雙分錄記賬的"不可變"哲學(xué)一脈相承。

Store 層：事務(wù)重試與死鎖防御

雙分錄記賬的寫入比單字段復(fù)雜得多。一筆轉(zhuǎn)賬要同時(shí)插入 transfers 記錄和兩條 entries 記錄，三者必須在同一個(gè)數(shù)據(jù)庫事務(wù)里。

但事務(wù)帶來新問題：并發(fā)寫入相同賬戶時(shí)，PostgreSQL 的行鎖可能引發(fā)死鎖。Paul 的解法是在 Store 層封裝 ExecTx 函數(shù)，自動檢測 pgx.ErrTxCommitRollback 錯(cuò)誤，用指數(shù)退避算法重試。重試邏輯寫在代碼里，而不是拋給調(diào)用方處理。

更細(xì)的設(shè)計(jì)是隔離級別。默認(rèn)的 Read Committed 在多數(shù)場景夠用，但涉及余額校驗(yàn)時(shí)可能需要 Repeatable Read。Paul 把隔離級別作為參數(shù)暴露，讓業(yè)務(wù)層按需選擇。

測試覆蓋了極端場景：并發(fā)轉(zhuǎn)賬、部分失敗、網(wǎng)絡(luò)中斷后的狀態(tài)一致性。用的不是 mock，而是 testcontainers 啟動真實(shí) PostgreSQL 容器，確保測試通過即生產(chǎn)可用。

Service 層：業(yè)務(wù)規(guī)則與賬本操作解耦

Store 層只管"怎么存"，Service 層決定"存什么"。這種分層讓單元測試可以 mock 數(shù)據(jù)庫，也讓業(yè)務(wù)邏輯不被 SQL 細(xì)節(jié)污染。

轉(zhuǎn)賬流程在 Service 層被拆解為：校驗(yàn)身份→檢查余額充足→創(chuàng)建 transfer 記錄→生成借貸 entries→提交事務(wù)。任何一步失敗，整個(gè)事務(wù)回滾，不會出現(xiàn)"錢扣了但沒到賬"的中間狀態(tài)。

余額檢查的實(shí)現(xiàn)值得一提。因?yàn)?entries 表只增不改，"當(dāng)前余額"是聚合計(jì)算的結(jié)果。Paul 在代碼里用 SELECT FOR UPDATE 鎖定相關(guān)賬戶的 entries 插入權(quán)限，同時(shí)計(jì)算 SUM(amount) 得到實(shí)時(shí)余額。這比 SELECT FOR UPDATE 鎖整張表更精細(xì)，并發(fā)性能更好。

貨幣處理也埋了細(xì)節(jié)。金額用 bigint 存最小單位（分），避免浮點(diǎn)誤差。幣種代碼硬校驗(yàn)，防止把 USD 和 EUR 混算。這些約束在數(shù)據(jù)庫層和代碼層各設(shè)一道，雙保險(xiǎn)。

從演示項(xiàng)目到生產(chǎn)系統(tǒng)

golangbank.app 的在線演示很完整：注冊、登錄、轉(zhuǎn)賬、查流水、導(dǎo)出報(bào)表。Swagger 文檔自動生成，前端用 Next.js 實(shí)現(xiàn)，前后端分離部署。

但生產(chǎn)環(huán)境還要補(bǔ)很多課。審計(jì)日志需要獨(dú)立存儲，防篡改；敏感操作要雙因素認(rèn)證；大額轉(zhuǎn)賬延遲結(jié)算，預(yù)留風(fēng)控窗口。Paul 的項(xiàng)目是骨架，血肉需要按業(yè)務(wù)填充。

一個(gè)值得參考的演進(jìn)方向是事件溯源（Event Sourcing）。entries 表本質(zhì)上已經(jīng)是事件流，如果加上 Kafka 或 Pulsar 做異步分發(fā)，就能支撐更復(fù)雜的業(yè)務(wù)：實(shí)時(shí)風(fēng)控、多幣種清算、甚至跨行對賬。

另一個(gè)方向是分片。entries 表隨時(shí)間膨脹，單機(jī) PostgreSQL 遲早觸頂。按賬戶ID哈希分片，或者按時(shí)間冷熱分離，都是常見策略。雙分錄記賬的優(yōu)勢在于：分片不影響一致性模型，因?yàn)槊抗P交易的借貸雙方可以落在不同分片，只要保證 transfers 記錄的完整性。

回到開頭的那行 UPDATE。在 Paul 的系統(tǒng)里，這句話永遠(yuǎn)不會出現(xiàn)。余額不是被修改的，而是被計(jì)算出來的；歷史不是被覆蓋的，而是被追加的。這種設(shè)計(jì)多寫了代碼，多占了存儲，但換來的是可審計(jì)、可回滾、可信任。

當(dāng)你的系統(tǒng)開始處理真金白銀，"簡單"往往是最貴的選擇。你愿意為這行消失的 UPDATE，多寫多少行代碼？