編輯導讀：不同部門、不同系統間要想做到信息共享就要建立同步機制，這樣才能確保數據互通，良性運營。本文以一個SaaS模式的“後台發貨系統”為例，分析它是如何做到庫存同步到銷售渠道的，希望對你有幫助。
後端產品體系的舊功能出了問題，只能在技術協助下，慢慢摸索追溯舊邏輯，搞清楚才能談得上優化。
本文主角是一個SaaS模式的“後台發貨系統”，對接美團等O2O平台的訂單。目的是將各銷售渠道的訂單統一管理，完成發貨。
既然統一發貨，就少不了做統一的庫存同步到銷售渠道的機制。這樣才能確保各平台數據互通，良性運營。
本次案例就來自庫存價格同步機制這塊的優化。
01 產品模型整個業務模型大概是這樣的：
該圖表自下往上，分別是：
- 最下是“商户WMS”：作為真實的門店和門店商品庫存、價格的來源。（因為是O2O，所以庫存就來自實體門店）。
- 圖中間是SaaS系統的“商户商品後台”：生成平台+線上門店+商品維度的數據清單，以銜接下端WMS和上端平台後台的數據。
- 最上面是O2O平台的後台：各渠道後台通過統一接口，統一在發貨系統中對接，節約成本，數據互通。
需注意的是：由於是O2O，同一商品，在不同平台的不同門店，價格可能不同。所以若有n個實體店，m個商品的話，那麼在每個平台，商户最多就要維護n*m條數據。
若w個銷售渠道（平台），那麼最多就要維護n*m*w條數據。這個客觀現實就為本次事件埋下伏筆。
02 核心功能：同步庫存、價格給第三方平台功能基於模型，所以正向功能就是：庫存價格變化，則同步到對應的各個平台。
觸發條件除了WMS增量自動同步之外，還需要手動觸發同步的機制。
比如，美團打折活動結束，就要觸發同步WMS的價格進行恢復。若此時不具有觸發增量的條件，就需要手動觸發。
於是增加了批量、單個<同步到平台>的功能。
至此，觸發同步的條件就確定了：單個同步、批量同步、增量自動同步。
功能流程如下圖：
總體機制：不同平台的商品，從WMS蒐集待同步的數據，然後集中後發車完成同步。
第一期的方案是採用“同步池”，彙集所有的同步請求。即：將來自於WMS的定時增量推送、頁面批量操作、單個操作的同步請求數據，集中在同步池中。
再按照各自的去向，尋找對應的平台接口，此時需服從各平台的限流規則。
限流規則：就是平台限制接口被請求的次數。比如美團限制每天只支持10萬次的同步請求。
整理後的技術實現流程圖：
主要有三個問題表現：同步池中的數據量會很大；經常量丟數據導致同步失敗；用户等待時間過長。
1. 數量大的原因1）基數大
由於各個平台和門店按照每個商户有200個連鎖店，每個商户有2000個商品，那麼就又有20萬條基礎數據。
若同時使用3個平台，最大就有60萬基礎數據。
2）觸發次數多
假設不同平台和門店在正常銷售，那麼WMS的庫存就會不停變化，於是就會不停地增量推送數據，請求同步到平台。
同時，商户又在單個或批量進行同步。商户為確保萬無一失還會選擇重複操作同步。
2. 丟數據的原因- 三方平台限流，提交過多的數據就被限制不執行。若平台不反饋失敗數據，那麼失敗後我們也不知道遺漏了哪些。
- 數據量過大，佔用線程擠滿，資源不夠。
目前平台的限流大致都是100條/秒，一個門店按照2000條商品，最快10秒完成，正常情況下20w商品數據需要近一小時。
總結以上，根源是數據量過大的問題。監控到2天有300w+的同步任務產生。
這就導致請求失敗過多，用户繼續重新同步，惡性循環，導致同步任務可能會很長一段時間無法降低，任務積壓。不丟都難。
05 優化方案1. 降低批量操作的頻次1）將同步庫存和同步價格按鈕分開
最初，同步庫存和價格的按鈕是在一起的，即<同步庫存價格>。
這就導致每點擊一下，就要同時同步庫存和價格到三方平台的後台。
而事實上，價格的變更很少見，而庫存的同步相對比較頻繁（任何一個平台的任何一個門店產生訂單，都會引發異動）。
如果不拆開，那麼每次的請求都雙份的（注：平台接口是支持拆開的）。
2）限制頻繁操作同步按鈕
同步庫存貨價格的按鈕點擊之後，若上個任務沒執行完，則按鈕不允許再次操作。
表面上看，若不做限制，貌似讓用户隨時用着爽，但實際上根本爽不起來。
2. 對同步池中的數據進行過濾1）只取時間戳最新的執行
根據唯一鍵，對重複提交進來的數據進行去重。
比如手動點擊同步，系統又自動增量同步，那麼這兩次請求只取最後這次的。
2）對比上次同步成功的數值，和本次提交的同步數值
如果數值沒變化，那麼同步過去也是無意義的，可以直接跳過這條任務。
比如上次已經同步過，且成功了，那麼這次就算手動觸發了同步，一旦對比到當前的價格和上次同步的價格是相同的，那就沒必要再次同步了。
3. 增加補推機制在同步給平台失敗的場景比較多。
若是數據本身不具備同步的條件，例如缺少默寫必須信息。或者不滿足平台的約束條件，比如平台無此數據。那麼只能返回原因，告訴用户處理後再試。
若是上述兩種條件都滿足，但是平台因為限流，導致部分數據遺留下來的話，理論上持續補推的話，總會完結的。
但是，考慮到後面還有很多數據在等待，所以這裏不能一直補推。
最終的方案就是間隔1s重新插入補推2次。
補推還不成功的，就停止補推，並彙報原因，便用户自己再手動同步。
4. 將同步池去掉，改為緩存池同步池其實是一張數據表。數據量攀升很快，需定期清理，也比較耗費時間。每次執行同步都調用池中數據，也耗性能。
現在改為從緩存中直接執行，動態線程。好處就是提升處理速度。
5. 增加同步狀態的展示和同步日誌在頁面對數據展示狀態：正常、失敗、異常
點擊狀態，展示同步日誌。方便用户自行發現異常。
06 總結1. 本次優化針對的是第三方數據同步的問題問題的根源在於數據量大，且三方平台限流。
解決方案要點：
- 減少來源，重點是前端的操作入口分離，並限制操作頻率。
- 對待處理數據進行清洗，去重、對比、改變存儲方式等。
- 增加失敗補償機制和日誌。
開源節流的思路：敲定場景、控制入口，清洗數據，處理併發，並輸出結果。
- 敲定場景：場景是無法無視的，場景確定，是做正確事的前提。當確定必須解決這個問題的時候，就可以靜下心找方案。
- 控制入口：因為數據量大，所以先從來源上做增益。
- 清洗數據：同樣是為了擺脱無效數據，儘可能降低冗餘。
- 處理併發：通過對比、時間戳等，濾掉無效數據。
- 生成日誌：讓用户有跡可循，自行追溯。
調研需求的時候，很難估計到數據的真實生態，以及第三方接口的各種限制。
因此只能在生產中發現和敲定問題。
4. 產品經理需瞭解技術機制這類問題屬於性能問題，本質屬於開發主導的範疇，但產品經理需瞭解這些機制。才能初期有所防備，後期及時處理。
#專欄作家#唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產品經理專欄作家，2019年年度作者。《後端產品經理寶典》作者，藥學碩士轉行互聯網產品多年；熟悉跨境電商業務，醫藥領域；擅長大型後台體系，社交APP。
本文原創發佈於人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基於CC0協議