今天講一個寫這個系列寫到中段才浮現的體悟——它會把前面二十幾天的線,一次收攏。

一台拆開的資料庫

有一天我盯著這個系統的全貌,突然發現它很眼熟:我們做的每一件事,都是一台資料庫內部構造的放大版。

留言清洗後先落地是 WAL(Day 3);FSM batch 消化留言建購物車,是 log consumer 在建索引;賣出數量是物化視圖(Day 7);付款狀態讀時派生是 view(Day 11);配貨紀錄可整段重建,是 redo log(Day 13);heartbeat 掃表是內建排程(Day 22);每小時重算,就是 repair。DDIA 最後一章管這個叫 unbundled database——把資料庫拆開,用一個個元件重新組裝。我們沒讀過那一章,卻用一年半把它蓋了出來。

拆開不是免費的。一台資料庫裡,index 永遠跟得上 heap、物化視圖有 refresh 保證、transaction 罩住一切;拆開之後,這些保證得自己補。對帳,理論上就是「自己補一致性」的最後一道防線——所以「我們沒做對帳」這件事,需要一個交代。

三本帳,誰會漂

先把三本帳和它們的 source of truth 攤開:

• 庫存帳:庫存上限+兩個消耗計數(購物車/訂單),一張獨立表、三個數字。
• 訂單帳:order 與 order item,金額在成交當下定格成會計事實。
• 金流帳:orders payment,配上 per-provider 的付款事實表。

帳會錯,必要條件是同一個事實存在兩份、而且各自更新——冗餘才會漂移。用這把尺量三本帳,結果很有趣:

**訂單帳和金流帳,幾乎沒有冗餘。**訂單「狀態」沒有一顆聚合的 status 欄位——各維度直接跟著事實走,聚合的判讀在讀取時發生;付款進度不是一個布林,是把 per-provider 事實表加總出來的。優惠金額用 floor-and-subtract,總和恆等是算法保證,不是事後核對出來的。沒有第二本會漂的帳,就沒有帳要對——這不是我們對帳做得好,是這兩本帳從結構上取消了對帳的必要。

**庫存帳,有一個冗餘。**賣出數量是全系統唯一刻意物化的數字——為了直播當下的速度,不物化不行。它也真的漂過:migrate 那次超賣(Day 8),就是這個數字被需求變更打歪。而它配的防線,就是每小時重算:照著購物車和訂單的事實,把計數整個算回來。一個冗餘,配一個修復迴圈,收支平衡。

所以「沒有對帳」的第一層答案:**對帳的需求,與物化的冗餘成正比。**我們把冗餘壓到只剩一個,對帳就縮到只剩一支排程——而它平常安靜到沒有人叫它對帳。

聽起來很完美?明天要誠實招認一件事:這個處理真金白銀的系統,沒有做對帳——而帳幾乎沒錯過。為什麼沒事,明天講。

本文改寫自我的部落格系列《Re:從零開始做直播代購電商平台》,本篇完整版:https://blog.aidan.tw/blog/rezero-reconciliation/