資料同步該怎麼設計？即時還是排程

先決定資料的主從關係

串接設計的第一個問題，也是最重要的問題：同一筆資料，以哪一邊為準？

例如商品價格，網站與 ERP 都有。如果兩邊都能改，改了不同的值，該聽誰的？

常見的三種安排

第一種最單純，也最不容易出錯。 如果 ERP 是庫存的主資料源，那網站後台的庫存欄位就應該設為唯讀，避免有人在網站端改了卻被下次同步覆蓋掉——那會讓人非常困惑。

第二種是實務上最常用的：價格、庫存、料號由 ERP 主導；商品照片、行銷文案、分類由網站主導。

即時同步還是排程同步

實務建議

• 訂單送出用即時——客戶下單後要盡快進入處理流程
• 庫存用高頻排程——例如每十分鐘或每小時，視商品週轉速度而定
• 商品與價格用低頻排程——每日一次通常足夠

不必全部都做成即時。即時同步的成本與風險都較高，只用在真正需要的地方。

庫存同步的特殊考量

庫存是最容易出問題的一項，因為它變動快、而且錯了會直接造成超賣。

兩個實務做法

• 保留安全庫存——ERP 顯示 10 件時，網站只開放 8 件。用緩衝吸收同步延遲
• 下單時再確認一次——結帳前即時向 ERP 查詢，確認確實有貨

第一種簡單但會犧牲部分銷售機會，第二種較準確但增加即時呼叫的次數。可以並用：平時排程同步，結帳時再確認。

超賣的相關處理見金流物流串接的常見問題。

失敗了怎麼辦

這是設計時一定要處理的，因為失敗必然會發生——對方系統維護、網路中斷、資料格式異常。

基本機制

1. 記錄失敗——時間、動作、資料、錯誤訊息
2. 自動重試——但要有次數上限，且間隔逐次拉長，避免持續衝擊對方
3. 超過次數後通知管理者
4. 提供手動重送——後台要能針對單筆重新執行

第四項很實用。沒有手動重送功能，一筆卡住的訂單就只能請廠商進資料庫處理。

不要重複執行

重試機制要注意：同一筆訂單不能被送出兩次。 常見做法是每次傳送帶一個唯一識別碼，讓對方能判斷是否已經處理過。

對帳機制

即使有失敗通知，仍建議定期核對兩邊的資料是否一致。

• 每日核對筆數——網站今天的訂單數與 ERP 收到的是否相同
• 定期核對金額
• 找出只存在於單邊的資料

差異越早發現越好處理。累積一個月的落差，追查起來會非常辛苦。

初次同步的規劃

上線時要把既有資料匯過去，這一步值得單獨規劃：

• 資料量大時要分批，避免一次執行造成負擔或逾時
• 先在測試環境跑一次，確認對應正確
• 保留原始資料的備份
• 驗證筆數與抽查內容

後台要能看到同步狀態

這是驗收時該確認的：

• 最後一次同步的時間與結果
• 失敗紀錄與錯誤訊息
• 單筆資料的同步狀態
• 手動觸發同步的功能

看不到狀態的串接，等於在黑箱中運作——出問題時只能猜。後台的紀錄功能見操作紀錄、備份與資料救回。