SaaS系統(tǒng)接口同步三方平臺的優(yōu)化方案后端產(chǎn)品體系的舊功能出了問題，只能在技術(shù)協(xié)助下，慢慢摸索追溯舊邏輯，搞清楚才能談得上優(yōu)化。本文主角是一個SaaS模式的“后臺發(fā)貨系統(tǒng)”，對接美團(tuán)等O2O平臺的訂單。目的是將各銷售渠道的訂單統(tǒng)一管理，完成發(fā)貨。既然統(tǒng)一發(fā)貨，就少不了做統(tǒng)一的庫存同步到銷售渠道的機(jī)制。這樣才能確保各平臺數(shù)據(jù)互通，良性運(yùn)營。本次案例就來自庫存價(jià)格同步機(jī)制這塊的優(yōu)化。01產(chǎn)品模型整個業(yè)務(wù)模型大概是這樣的：該圖表自下往上，分別是：最下是“商戶WMS”：作為真實(shí)的門店和門店商品庫存、價(jià)格的來源。（因?yàn)槭荗2O，所以庫存就來自實(shí)體門店）。圖中間是SaaS系統(tǒng)的“商戶商品后臺”：生成平臺+線上門店+商品維度的數(shù)據(jù)清單，以銜接下端WMS和上端平臺后臺的數(shù)據(jù)。最上面是O2O平臺的后臺：各渠道后臺通過統(tǒng)一接口，統(tǒng)一在發(fā)貨系統(tǒng)中對接，節(jié)約成本，數(shù)據(jù)互通。需注意的是：由于是O2O，同一商品，在不同平臺的不同門店，價(jià)格可能不同。所以若有n個實(shí)體店，m個商品的話，那么在每個平臺，商戶最多就要維護(hù)n*m條數(shù)據(jù)。若w個銷售渠道（平臺），那么最多就要維護(hù)n*m*w條數(shù)據(jù)。這個客觀現(xiàn)實(shí)就為本次事件埋下伏筆。02核心功能：同步庫存、價(jià)格給第三方平臺功能基于模型，所以正向功能就是：庫存價(jià)格變化，則同步到對應(yīng)的各個平臺。觸發(fā)條件除了WMS增量自動同步之外，還需要手動觸發(fā)同步的機(jī)制。比如，美團(tuán)打折活動結(jié)束，就要觸發(fā)同步WMS的價(jià)格進(jìn)行恢復(fù)。若此時不具有觸發(fā)增量的條件，就需要手動觸發(fā)。于是增加了批量、單個<同步到平臺>的功能。至此，觸發(fā)同步的條件就確定了：單個同步、批量同步、增量自動同步。功能流程如下圖：03技術(shù)實(shí)現(xiàn)機(jī)制總體機(jī)制：不同平臺的商品，從WMS搜集待同步的數(shù)據(jù)，然后集中后發(fā)車完成同步。第一期的方案是采用“同步池”，匯集所有的同步請求。即：將來自于WMS的定時增量推送、頁面批量操作、單個操作的同步請求數(shù)據(jù)，集中在同步池中。再按照各自的去向，尋找對應(yīng)的平臺接口，此時需服從各平臺的限流規(guī)則。限流規(guī)則：就是平臺限制接口被請求的次數(shù)。比如美團(tuán)限制每天只支持10萬次的同步請求。整理后的技術(shù)實(shí)現(xiàn)流程圖：04出現(xiàn)的問題主要有三個問題表現(xiàn)：同步池中的數(shù)據(jù)量會很大；經(jīng)常量丟數(shù)據(jù)導(dǎo)致同步失??；用戶等待時間過長。1.數(shù)量大的原因1）基數(shù)大由于各個平臺和門店按照每個商戶有200個連鎖店，每個商戶有2000個商品，那么就又有20萬條基礎(chǔ)數(shù)據(jù)。若同時使用3個平臺，最大就有60萬基礎(chǔ)數(shù)據(jù)。2）觸發(fā)次數(shù)多假設(shè)不同平臺和門店在正常銷售，那么WMS的庫存就會不停變化，于是就會不停地增量推送數(shù)據(jù)，請求同步到平臺。同時，商戶又在單個或批量進(jìn)行同步。商戶為確保萬無一失還會選擇重復(fù)操作同步。2.丟數(shù)據(jù)的原因三方平臺限流，提交過多的數(shù)據(jù)就被限制不執(zhí)行。若平臺不反饋失敗數(shù)據(jù)，那么失敗后我們也不知道遺漏了哪些。數(shù)據(jù)量過大，占用線程擠滿，資源不夠。3.執(zhí)行時間太久的原因目前平臺的限流大致都是100條/秒，一個門店按照2000條商品，最快10秒完成，正常情況下20w商品數(shù)據(jù)需要近一小時?？偨Y(jié)以上，根源是數(shù)據(jù)量過大的問題。監(jiān)控到2天有300w+的同步任務(wù)產(chǎn)生。這就導(dǎo)致請求失敗過多，用戶繼續(xù)重新同步，惡性循環(huán)，導(dǎo)致同步任務(wù)可能會很長一段時間無法降低，任務(wù)積壓。不丟都難。05優(yōu)化方案1.降低批量操作的頻次1）將同步庫存和同步價(jià)格按鈕分開最初，同步庫存和價(jià)格的按鈕是在一起的，即<同步庫存價(jià)格>。這就導(dǎo)致每點(diǎn)擊一下，就要同時同步庫存和價(jià)格到三方平臺的后臺。而事實(shí)上，價(jià)格的變更很少見，而庫存的同步相對比較頻繁（任何一個平臺的任何一個門店產(chǎn)生訂單，都會引發(fā)異動）。如果不拆開，那么每次的請求都雙份的（注：平臺接口是支持拆開的）。2）限制頻繁操作同步按鈕同步庫存貨價(jià)格的按鈕點(diǎn)擊之后，若上個任務(wù)沒執(zhí)行完，則按鈕不允許再次操作。表面上看，若不做限制，貌似讓用戶隨時用著爽，但實(shí)際上根本爽不起來。2.對同步池中的數(shù)據(jù)進(jìn)行過濾1）只取時間戳最新的執(zhí)行根據(jù)唯一鍵，對重復(fù)提交進(jìn)來的數(shù)據(jù)進(jìn)行去重。比如手動點(diǎn)擊同步，系統(tǒng)又自動增量同步，那么這兩次請求只取最后這次的。2）對比上次同步成功的數(shù)值，和本次提交的同步數(shù)值如果數(shù)值沒變化，那么同步過去也是無意義的，可以直接跳過這條任務(wù)。比如上次已經(jīng)同步過，且成功了，那么這次就算手動觸發(fā)了同步，一旦對比到當(dāng)前的價(jià)格和上次同步的價(jià)格是相同的，那就沒必要再次同步了。3.增加補(bǔ)推機(jī)制在同步給平臺失敗的場景比較多。若是數(shù)據(jù)本身不具備同步的條件，例如缺少默寫必須信息?；蛘卟粷M足平臺的約束條件，比如平臺無此數(shù)據(jù)。那么只能返回原因，告訴用戶處理后再試。若是上述兩種條件都滿足，但是平臺因?yàn)橄蘖鳎瑢?dǎo)致部分?jǐn)?shù)據(jù)遺留下來的話，理論上持續(xù)補(bǔ)推的話，總會完結(jié)的。但是，考慮到后面還有很多數(shù)據(jù)在等待，所以這里不能一直補(bǔ)推。最終的方案就是間隔1s重新插入補(bǔ)推2次。補(bǔ)推還不成功的，就停止補(bǔ)推，并匯報(bào)原因，便用戶自己再手動同步。4.將同步池去掉，改為緩存池同步池其實(shí)是一張數(shù)據(jù)表。數(shù)據(jù)量攀升很快，需定期清理，也比較耗費(fèi)時間。每次執(zhí)行同步都調(diào)用池中數(shù)據(jù)，也耗性能?，F(xiàn)在改為從緩存中直接執(zhí)行，動態(tài)線程。好處就是提升處理速度。5.增加同步狀態(tài)的展示和同步日志在頁面對數(shù)據(jù)展示狀態(tài)：正常、失敗、異常點(diǎn)擊狀態(tài)，展示同步日志。方便用戶自行發(fā)現(xiàn)異常。06總結(jié)1.本次優(yōu)化針對的是第三方數(shù)據(jù)同步的問題問題的根源在于數(shù)據(jù)量大，且三方平臺限流。解決方案要點(diǎn)：減少來源，重點(diǎn)是前端的操作入口分離，并限制操作頻率。對待處理數(shù)據(jù)進(jìn)行清洗，去重、對比、改變存儲方式等。增加失敗補(bǔ)償機(jī)制和日志。2.解決思路模型開源節(jié)流的思路：敲定場景、控制入口，清洗數(shù)據(jù)，處理并發(fā)，并輸出結(jié)果。敲定場景：場景是無法無視的，場景確定，是做正確事的前提。當(dāng)確定必須解決這個問題的時候，就可以靜下心找方案?？刂迫肟冢阂?yàn)閿?shù)據(jù)量大，所以先從來源上做增益。清洗數(shù)據(jù)：同樣是為了擺脫無效數(shù)據(jù)，盡可能降低冗余。處理并發(fā)：通過對比、時間戳等，濾掉無效數(shù)據(jù)。生成日志：讓用戶有跡可循，自行