淘寶店鋪訂單同步解決方案-摘記

項目背景

最近作一個電子商務平臺的投標工做，寫技術標過程當中，碰到須要和淘寶集成的接口，其中有一個需求就是須要將目前ERP系統中的訂單和淘寶店鋪中訂單進行同步，具體需求以下描述：
一、零售、批銷、代銷、機構訂單都存儲在客戶的ERP系統當中；
二、淘寶商城的訂單存儲在淘寶中，ERP系統中不存在；
三、目前投標的電子商務平臺中商品訂單付款成功後須要將訂單轉入到ERP系統處理。
針對以上需求，咱們對淘寶的開放平臺接口作了分析，其中淘寶已經提供相似場景的解決方案，具體的方案將在下面作具體的介紹。

淘寶解決方案背景說明

訂單是賣家的核心數據，賣家的不少平常工做都是圍繞着訂單展開，應用的基本功能就是要保證訂單實時、完整的展現在賣家面前。因爲API請求依賴於網絡，存在着網絡不穩定和同步時間長的問題，因此應用必須把淘寶的訂單數據同步到本地。如何才能快速、完整的把訂單同步到本地是本方案將要討論的問題。

 

名詞解釋

在線訂單：賣家三個月內已賣出的訂單。
增量訂單：相對已經同步到本地的訂單，凡是在淘寶上發生了變動的訂單就是增量訂單。
主動通知：一種經過HTTP長鏈接實時向客戶端（應用）推送數據（交易）變動的渠道。
異步API：把業務請求與業務處理分開執行、把業務邏輯與海量計算轉移到淘寶、而且結果可異步下載的API。

API介紹

taobao.trades.sold.get
獲取三個月內已賣出的在線訂單，適用於用戶初始化的時候使用，ISV不該該用此接口來獲取增量訂單。
不建議使用或儘可能少用此接口。
taobao.trades.sold.increment.get
獲取增量訂單，適用於用戶初始化後，增量同步發生變動的訂單，ISV不該該用此接口來獲取三個月內的訂單。
taobao.topats.trades.sold.get
異步獲取三個月內已賣出的在線訂單，具備簡單、高效、準確的特色，而且支持超大賣家，適用於用戶初始化的時候使用，強烈建議採用此接口代替taobao.trades.sold.get接口，以提高效率、下降開發成本。
taobao.trade.fullinfo.get – 獲取單筆訂單詳情。
taobao.topats.trades.fullinfo.get – 批量獲取最多100筆訂單詳情。

實施方案

訂單同步主要分爲初始化和增量獲取兩個步驟：
1. 初始化是把3個月內的在線訂單所有同步回來，這個須要較長的時間；
2. 增量獲取則是把淘寶發生了變動的訂單同步回來，這個通常須要較短的時間。
下面的方案都會圍繞着如何初始化和增量獲取來說。
方案一
同步流程：

核心步驟：

一、三個月數據：經過taobao.trades.sold.get獲取3個月內到如今建立的訂單ID，再經過taobao.trade.fullinfo.get獲取訂單詳情
二、增量數據：經過taobao.trades.sold.increment.get獲取從如今開始的增量訂單ID，再經過taobao.trade.fullinfo.get獲取訂單詳情
適用範圍：
適用於ISV測試訂單同步功能或生產環境的中小賣家進行訂單同步。此方案比較低效，除非老的應用更新成本很高，不然不推薦你們使用，建議採用下面的方案。
方案二
同步流程：

核心步驟：

一、三個月數據：經過taobao.topats.trades.sold.get異步獲取3個月內到昨天23:59:59建立的訂單詳情
二、增量數據：經過taobao.trades.sold.increment.get獲取從今天00:00:00開始的增量訂單ID，再經過taobao.trade.fullinfo.get獲取訂單詳情。
適用範圍：
適用於全部類型的賣家，尤爲是大賣家採用此方案能夠極大的提升同步速度，對於超大型的賣家（如直充、金冠級別的賣家）也能很好的支持。
方案三
同步流程：

核心步驟：

一、三個月數據：
a) 首先，經過taobao.topats.trades.sold.get異步獲取3個月內到昨天23:59:59建立的訂單詳情
b) 而後，經過taobao.trades.sold.increment.get獲取從今天00:00:00到如今的增量訂單ID，再經過taobao.trade.fullinfo.get獲取訂單詳情
二、增量數據：經過主動通知客戶端實時監聽訂單變動消息，再經過taobao.trade.fullinfo.get獲取訂單詳情
適用範圍：
適用於全部類型的賣家，是全部方案中相對複雜，但效率最高的方案，推薦全部ISV採用。

經驗分享

漏單問題：
一、經過taobao.trades.sold.get和taobao.trades.sold.increment.get獲取訂單時，交易類型type入參默認只查詢部分類型的訂單，要查詢全部類型的訂單，必須顯式提供全部交易類型做爲type入參。
二、經過taobao.trades.sold.increment.get獲取增量訂單時，返回結果是按訂單修改時間倒序排序的，分頁必須從後往前翻，防止正向翻頁過程當中訂單發生變動而致使漏單。
三、經過taobao.trades.sold.increment.get獲取增量訂單時，每次獲取的起始時間適當前移10分鐘左右（雙11大促時建議前移30分鐘左右），防止極端狀況下因爲淘寶系統壓力而致使訂單延遲更新到數據庫而產生的漏單。
四、經過主動通知接收訂單變動消息時，須要處理服務器重啓或網絡斷開鏈接而致使的消息丟失問題，詳細內容請查看主動通知文檔。
性能問題：
一、taobao.trades.sold.get獲取三個月已賣家的訂單
a) 採用入參use_has_next=true的分頁方式能夠避免每次API請求對淘寶數據庫產生的count(*)，從而顯著提高速度和穩定性。
b) 因爲獲取三個月內的訂單接口是用建立時間過濾的，而建立時間是不可變的，因此從前日後翻頁也不會致使漏單，於是能夠省掉第一步的count(*)，而直接採用入參use_has_next=true的方式分頁獲取，直到返回結果中has_next=false時終止翻頁。
c) 若是接口返回的字段沒法知足應用的須要，則強烈建議只獲取fields=tid這一個字段，而後再經過taobao.trade.fullinfo.get獲取訂單詳情。
d) 因爲賣家三個月訂單量比較大，建議把三個月的訂單切分紅按天獲取，減小單次請求對淘寶數據庫的記錄掃描量，以提高效率。
二、taobao.trades.sold.increment.get獲取增量訂單
a) 採用入參use_has_next=true的分頁方式能夠避免每次API請求時對淘寶數據庫產生的count(*)，從而顯著提高速度和穩定性。
b) 因爲獲取增量訂單接口是用修改時間過濾的，而修改時間是可變的，因此須要從後往前翻頁才能避免漏單。從後往前翻頁必需要知道最後一頁，因此必須在首次API請求時採用use_has_next=false方式統計訂單總數，計算出總頁數，而後再設置use_has_next=true終止訂單統計，從後往前翻頁。
c) 若是接口返回的字段沒法知足應用的須要，則強烈建議只獲取fields=tid這一個字段，而後再經過taobao.trade.fullinfo.get獲取訂單詳情。
三、使用taobao.trades.sold.get/taobao.trades.sold.increment.get只獲取tid字段時，建議設置page_size爲最大值，減小API請求次數，提高效率。獲取多個字段時可根據自身的網絡狀況設置page_size，建議設置爲50左右。
異常處理：
一、同步訂單通常會採用多線程處理，因爲API請求對APP是有頻率限制的，因此設置線程池大小時，須要根據TOP容許的API調用頻率來設置，避免限流後致使應用長時間沒法調用API。
二、對於API返回的ISP類型的錯誤或網絡鏈接錯誤，應用線程應該在休眠片刻中自動重試。而對於API返回的ISV類型的錯誤，應用須要記錄日誌以便往後排查，同時不要重試。

示例代碼

API接口文檔及示例代碼：http://open.taobao.com/doc2/apiList?spm=0.0.0.0.SJHRH3&cid=5

 

文章做者： iitshare
本文地址：http://www.iitshare.com/taobao-shop-orders-synchronization.html
版權全部 © 轉載時必須以連接形式註明做者和原始出處！