編輯導(dǎo)讀：不同部門(mén)、不同系統(tǒng)間要想做到信息共享就要建立同步機(jī)制，這樣才能確保數(shù)據(jù)互通，良性運(yùn)營(yíng)。本文以一個(gè)SaaS模式的“后臺(tái)發(fā)貨系統(tǒng)”為例，分析它是如何做到庫(kù)存同步到銷(xiāo)售渠道的，希望對(duì)你有幫助。

后端產(chǎn)品體系的舊功能出了問(wèn)題，只能在技術(shù)協(xié)助下，慢慢摸索追溯舊邏輯，搞清楚才能談得上優(yōu)化。

本文主角是一個(gè)SaaS模式的“后臺(tái)發(fā)貨系統(tǒng)”，對(duì)接美團(tuán)等O2O平臺(tái)的訂單。目的是將各銷(xiāo)售渠道的訂單統(tǒng)一管理，完成發(fā)貨。

既然統(tǒng)一發(fā)貨，就少不了做統(tǒng)一的庫(kù)存同步到銷(xiāo)售渠道的機(jī)制。這樣才能確保各平臺(tái)數(shù)據(jù)互通，良性運(yùn)營(yíng)。

本次案例就來(lái)自庫(kù)存價(jià)格同步機(jī)制這塊的優(yōu)化。

01 產(chǎn)品模型

整個(gè)業(yè)務(wù)模型大概是這樣的：

該圖表自下往上，分別是：

• 最下是“商戶WMS”：作為真實(shí)的門(mén)店和門(mén)店商品庫(kù)存、價(jià)格的來(lái)源。（因?yàn)槭荗2O，所以庫(kù)存就來(lái)自實(shí)體門(mén)店）。
• 圖中間是SaaS系統(tǒng)的“商戶商品后臺(tái)”：生成平臺(tái)+線上門(mén)店+商品維度的數(shù)據(jù)清單，以銜接下端WMS和上端平臺(tái)后臺(tái)的數(shù)據(jù)。
• 最上面是O2O平臺(tái)的后臺(tái)：各渠道后臺(tái)通過(guò)統(tǒng)一接口，統(tǒng)一在發(fā)貨系統(tǒng)中對(duì)接，節(jié)約成本，數(shù)據(jù)互通。

需注意的是：由于是O2O，同一商品，在不同平臺(tái)的不同門(mén)店，價(jià)格可能不同。所以若有n個(gè)實(shí)體店，m個(gè)商品的話，那么在每個(gè)平臺(tái)，商戶最多就要維護(hù)n*m條數(shù)據(jù)。

若w個(gè)銷(xiāo)售渠道（平臺(tái)），那么最多就要維護(hù)n*m*w條數(shù)據(jù)。這個(gè)客觀現(xiàn)實(shí)就為本次事件埋下伏筆。

02 核心功能：同步庫(kù)存、價(jià)格給第三方平臺(tái)

功能基于模型，所以正向功能就是：庫(kù)存價(jià)格變化，則同步到對(duì)應(yīng)的各個(gè)平臺(tái)。

觸發(fā)條件除了WMS增量自動(dòng)同步之外，還需要手動(dòng)觸發(fā)同步的機(jī)制。

比如，美團(tuán)打折活動(dòng)結(jié)束，就要觸發(fā)同步WMS的價(jià)格進(jìn)行恢復(fù)。若此時(shí)不具有觸發(fā)增量的條件，就需要手動(dòng)觸發(fā)。

于是增加了批量、單個(gè)<同步到平臺(tái)>的功能。

至此，觸發(fā)同步的條件就確定了：?jiǎn)蝹€(gè)同步、批量同步、增量自動(dòng)同步。

功能流程如下圖：

03 技術(shù)實(shí)現(xiàn)機(jī)制

總體機(jī)制：不同平臺(tái)的商品，從WMS搜集待同步的數(shù)據(jù)，然后集中后發(fā)車(chē)完成同步。

第一期的方案是采用“同步池”，匯集所有的同步請(qǐng)求。即：將來(lái)自于WMS的定時(shí)增量推送、頁(yè)面批量操作、單個(gè)操作的同步請(qǐng)求數(shù)據(jù)，集中在同步池中。

再按照各自的去向，尋找對(duì)應(yīng)的平臺(tái)接口，此時(shí)需服從各平臺(tái)的限流規(guī)則。

限流規(guī)則：就是平臺(tái)限制接口被請(qǐng)求的次數(shù)。比如美團(tuán)限制每天只支持10萬(wàn)次的同步請(qǐng)求。

整理后的技術(shù)實(shí)現(xiàn)流程圖：

04 出現(xiàn)的問(wèn)題

主要有三個(gè)問(wèn)題表現(xiàn)：同步池中的數(shù)據(jù)量會(huì)很大；經(jīng)常量丟數(shù)據(jù)導(dǎo)致同步失??；用戶等待時(shí)間過(guò)長(zhǎng)。

1. 數(shù)量大的原因

1）基數(shù)大

由于各個(gè)平臺(tái)和門(mén)店按照每個(gè)商戶有200個(gè)連鎖店，每個(gè)商戶有2000個(gè)商品，那么就又有20萬(wàn)條基礎(chǔ)數(shù)據(jù)。

若同時(shí)使用3個(gè)平臺(tái)，最大就有60萬(wàn)基礎(chǔ)數(shù)據(jù)。

2）觸發(fā)次數(shù)多

假設(shè)不同平臺(tái)和門(mén)店在正常銷(xiāo)售，那么WMS的庫(kù)存就會(huì)不停變化，于是就會(huì)不停地增量推送數(shù)據(jù)，請(qǐng)求同步到平臺(tái)。

同時(shí)，商戶又在單個(gè)或批量進(jìn)行同步。商戶為確保萬(wàn)無(wú)一失還會(huì)選擇重復(fù)操作同步。

2. 丟數(shù)據(jù)的原因

• 三方平臺(tái)限流，提交過(guò)多的數(shù)據(jù)就被限制不執(zhí)行。若平臺(tái)不反饋失敗數(shù)據(jù)，那么失敗后我們也不知道遺漏了哪些。
• 數(shù)據(jù)量過(guò)大，占用線程擠滿，資源不夠。

3. 執(zhí)行時(shí)間太久的原因

目前平臺(tái)的限流大致都是100條/秒，一個(gè)門(mén)店按照2000條商品，最快10秒完成，正常情況下20w商品數(shù)據(jù)需要近一小時(shí)。

總結(jié)以上，根源是數(shù)據(jù)量過(guò)大的問(wèn)題。監(jiān)控到2天有300w+的同步任務(wù)產(chǎn)生。

這就導(dǎo)致請(qǐng)求失敗過(guò)多，用戶繼續(xù)重新同步，惡性循環(huán)，導(dǎo)致同步任務(wù)可能會(huì)很長(zhǎng)一段時(shí)間無(wú)法降低，任務(wù)積壓。不丟都難。

05 優(yōu)化方案

1. 降低批量操作的頻次

1）將同步庫(kù)存和同步價(jià)格按鈕分開(kāi)

最初，同步庫(kù)存和價(jià)格的按鈕是在一起的，即<同步庫(kù)存價(jià)格>。

這就導(dǎo)致每點(diǎn)擊一下，就要同時(shí)同步庫(kù)存和價(jià)格到三方平臺(tái)的后臺(tái)。

而事實(shí)上，價(jià)格的變更很少見(jiàn)，而庫(kù)存的同步相對(duì)比較頻繁（任何一個(gè)平臺(tái)的任何一個(gè)門(mén)店產(chǎn)生訂單，都會(huì)引發(fā)異動(dòng)）。

如果不拆開(kāi)，那么每次的請(qǐng)求都雙份的（注：平臺(tái)接口是支持拆開(kāi)的）。

2）限制頻繁操作同步按鈕

同步庫(kù)存貨價(jià)格的按鈕點(diǎn)擊之后，若上個(gè)任務(wù)沒(méi)執(zhí)行完，則按鈕不允許再次操作。

表面上看，若不做限制，貌似讓用戶隨時(shí)用著爽，但實(shí)際上根本爽不起來(lái)。

2. 對(duì)同步池中的數(shù)據(jù)進(jìn)行過(guò)濾

1）只取時(shí)間戳最新的執(zhí)行

根據(jù)唯一鍵，對(duì)重復(fù)提交進(jìn)來(lái)的數(shù)據(jù)進(jìn)行去重。

比如手動(dòng)點(diǎn)擊同步，系統(tǒng)又自動(dòng)增量同步，那么這兩次請(qǐng)求只取最后這次的。

2）對(duì)比上次同步成功的數(shù)值，和本次提交的同步數(shù)值

如果數(shù)值沒(méi)變化，那么同步過(guò)去也是無(wú)意義的，可以直接跳過(guò)這條任務(wù)。

比如上次已經(jīng)同步過(guò)，且成功了，那么這次就算手動(dòng)觸發(fā)了同步，一旦對(duì)比到當(dāng)前的價(jià)格和上次同步的價(jià)格是相同的，那就沒(méi)必要再次同步了。

3. 增加補(bǔ)推機(jī)制

在同步給平臺(tái)失敗的場(chǎng)景比較多。

若是數(shù)據(jù)本身不具備同步的條件，例如缺少默寫(xiě)必須信息?；蛘卟粷M足平臺(tái)的約束條件，比如平臺(tái)無(wú)此數(shù)據(jù)。那么只能返回原因，告訴用戶處理后再試。

若是上述兩種條件都滿足，但是平臺(tái)因?yàn)橄蘖?，?dǎo)致部分?jǐn)?shù)據(jù)遺留下來(lái)的話，理論上持續(xù)補(bǔ)推的話，總會(huì)完結(jié)的。

但是，考慮到后面還有很多數(shù)據(jù)在等待，所以這里不能一直補(bǔ)推。

最終的方案就是間隔1s重新插入補(bǔ)推2次。

補(bǔ)推還不成功的，就停止補(bǔ)推，并匯報(bào)原因，便用戶自己再手動(dòng)同步。

4. 將同步池去掉，改為緩存池

同步池其實(shí)是一張數(shù)據(jù)表。數(shù)據(jù)量攀升很快，需定期清理，也比較耗費(fèi)時(shí)間。每次執(zhí)行同步都調(diào)用池中數(shù)據(jù)，也耗性能。

現(xiàn)在改為從緩存中直接執(zhí)行，動(dòng)態(tài)線程。好處就是提升處理速度。

5. 增加同步狀態(tài)的展示和同步日志

在頁(yè)面對(duì)數(shù)據(jù)展示狀態(tài)：正常、失敗、異常

點(diǎn)擊狀態(tài)，展示同步日志。方便用戶自行發(fā)現(xiàn)異常。

06 總結(jié)

1. 本次優(yōu)化針對(duì)的是第三方數(shù)據(jù)同步的問(wèn)題

問(wèn)題的根源在于數(shù)據(jù)量大，且三方平臺(tái)限流。

解決方案要點(diǎn)：

1. 減少來(lái)源，重點(diǎn)是前端的操作入口分離，并限制操作頻率。
2. 對(duì)待處理數(shù)據(jù)進(jìn)行清洗，去重、對(duì)比、改變存儲(chǔ)方式等。
3. 增加失敗補(bǔ)償機(jī)制和日志。

2. 解決思路模型

開(kāi)源節(jié)流的思路：敲定場(chǎng)景、控制入口，清洗數(shù)據(jù)，處理并發(fā)，并輸出結(jié)果。

• 敲定場(chǎng)景：場(chǎng)景是無(wú)法無(wú)視的，場(chǎng)景確定，是做正確事的前提。當(dāng)確定必須解決這個(gè)問(wèn)題的時(shí)候，就可以靜下心找方案。
• 控制入口：因?yàn)閿?shù)據(jù)量大，所以先從來(lái)源上做增益。
• 清洗數(shù)據(jù)：同樣是為了擺脫無(wú)效數(shù)據(jù)，盡可能降低冗余。
• 處理并發(fā)：通過(guò)對(duì)比、時(shí)間戳等，濾掉無(wú)效數(shù)據(jù)。
• 生成日志：讓用戶有跡可循，自行追溯。

3. 這類(lèi)問(wèn)題初期很難預(yù)測(cè)

調(diào)研需求的時(shí)候，很難估計(jì)到數(shù)據(jù)的真實(shí)生態(tài)，以及第三方接口的各種限制。

因此只能在生產(chǎn)中發(fā)現(xiàn)和敲定問(wèn)題。

4. 產(chǎn)品經(jīng)理需了解技術(shù)機(jī)制

這類(lèi)問(wèn)題屬于性能問(wèn)題，本質(zhì)屬于開(kāi)發(fā)主導(dǎo)的范疇，但產(chǎn)品經(jīng)理需了解這些機(jī)制。才能初期有所防備，后期及時(shí)處理。

#專(zhuān)欄作家#

唧唧歪歪PM，公眾號(hào)：唧唧歪歪PM（ID：jjyypm），人人都是產(chǎn)品經(jīng)理專(zhuān)欄作家，2019年年度作者。《后端產(chǎn)品經(jīng)理寶典》作者，藥學(xué)碩士轉(zhuǎn)行互聯(lián)網(wǎng)產(chǎn)品多年；熟悉跨境電商業(yè)務(wù)，醫(yī)藥領(lǐng)域；擅長(zhǎng)大型后臺(tái)體系，社交APP。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議