背景

訂單是賣家的核心數(shù)據(jù)，賣家的很多日常工作都是圍繞著訂單展開，應(yīng)用的基本功能就是要保證訂單實時、完整的展示在賣家面前。由于API請求依賴于網(wǎng)絡(luò)，存在著網(wǎng)絡(luò)不穩(wěn)定和同步時間長的問題，所以應(yīng)用必須把淘寶的訂單數(shù)據(jù)同步到本地。如何才能快速、完整的把訂單同步到本地是本方案將要討論的問題。

訂單同步有兩種方式：1、通過api 同步  2、基于rds訂單同步服務(wù) 。本文主要分析使用api 同步訂單的場景，有關(guān)rds訂單同步使用方法，可參考 //open.taobao.com/docs/doc.htm.htm?articleId=101587&docType=1&treeId=2

名詞解釋

在線訂單：賣家三個月內(nèi)已賣出的訂單。

增量訂單：相對已經(jīng)同步到本地的訂單，凡是在淘寶上發(fā)生了變更的訂單就是增量訂單。

消息服務(wù)：一種通過HTTP長連接實時向客戶端（應(yīng)用）推送數(shù)據(jù)（交易）變更的渠道。

API介紹

taobao.trades.sold.get - 獲取三個月內(nèi)已賣出的在線訂單，適用于用戶初始化的時候使用，ISV不應(yīng)該用此接口來獲取增量訂單。不建議使用或盡量少用此接口。

taobao.trades.sold.increment.get – 獲取增量訂單，適用于用戶初始化后，增量同步發(fā)生變更的訂單，ISV不應(yīng)該用此接口來獲取三個月內(nèi)的訂單。

taobao.trade.fullinfo.get - 獲取單筆訂單詳情。

實施方案

訂單同步主要分為初始化和增量獲取兩個步驟：

1. 初始化是把3個月內(nèi)的在線訂單全部同步回來，這個需要較長的時間；

2. 增量獲取則是把淘寶發(fā)生了變更的訂單同步回來，這個一般需要較短的時間。

下面的方案都會圍繞著如何初始化和增量獲取來講。

1 

2 

方案一

同步流程：

核心步驟：

u  三個月數(shù)據(jù)：通過taobao.trades.sold.get獲取3個月內(nèi)到現(xiàn)在創(chuàng)建的訂單ID，再通過taobao.trade.fullinfo.get獲取訂單詳情

u 增量數(shù)據(jù)：通過taobao.trades.sold.increment.get獲取從現(xiàn)在開始的增量訂單ID，再通過taobao.trade.fullinfo.get獲取訂單詳情

適用范圍：

適用于ISV測試訂單同步功能或生產(chǎn)環(huán)境的中小賣家進(jìn)行訂單同步。此方案比較低效，除非老的應(yīng)用更新成本很高，否則不推薦大家使用，建議采用下面的方案。

方案二

同步流程：

核心步驟： 

a)  首先，通過taobao.trades.sold.get獲取3個月內(nèi)到昨天23:59:59創(chuàng)建的訂單詳情

u  三個月數(shù)據(jù)：

b)  然后，通過taobao.trades.sold.increment.get獲取從今天00:00:00到現(xiàn)在的增量訂單ID，再通過taobao.trade.fullinfo.get獲取訂單詳情

u  增量數(shù)據(jù)：通過消息服務(wù)客戶端實時監(jiān)聽訂單變更消息，再通過taobao.trade.fullinfo.get獲取訂單詳情

適用范圍：

適用于所有類型的賣家，是所有方案中相對復(fù)雜，但效率最高的方案，推薦所有ISV采用。

經(jīng)驗分享

漏單問題：

M  通過taobao.trades.sold.get和taobao.trades.sold.increment.get獲取訂單時，交易類型type入?yún)⒛J(rèn)只查詢部分類型的訂單，要查詢所有類型的訂單，必須顯式提供所有交易類型作為type入?yún)ⅰ?/span>

M  通過taobao.trades.sold.increment.get獲取增量訂單時，返回結(jié)果是按訂單修改時間倒序排序的，分頁必須從后往前翻，防止正向翻頁過程中訂單發(fā)生變更而導(dǎo)致漏單。

M  通過taobao.trades.sold.increment.get獲取增量訂單時，每次獲取的起始時間適當(dāng)前移10分鐘左右（雙11大促時建議前移30分鐘左右），防止極端情況下由于淘寶系統(tǒng)壓力而導(dǎo)致訂單延遲更新到數(shù)據(jù)庫而產(chǎn)生的漏單。

M  通過主動通知接收訂單變更消息時，需要處理服務(wù)器重啟或網(wǎng)絡(luò)斷開連接而導(dǎo)致的消息丟失問題，詳細(xì)內(nèi)容請查看消息服務(wù)。

性能問題：

M  taobao.trades.sold.get獲取三個月已賣家的訂單

n  采用入?yún)se_has_next=true的分頁方式可以避免每次API請求對淘寶數(shù)據(jù)庫產(chǎn)生的count(*)，從而顯著提升速度和穩(wěn)定性。

n  由于獲取三個月內(nèi)的訂單接口是用創(chuàng)建時間過濾的，而創(chuàng)建時間是不可變的，所以從前往后翻頁也不會導(dǎo)致漏單，因而可以省掉第一步的count(*)，而直接采用入?yún)se_has_next=true的方式分頁獲取，直到返回結(jié)果中has_next=false時終止翻頁。

n  如果接口返回的字段無法滿足應(yīng)用的需要，則強(qiáng)烈建議只獲取fields=tid這一個字段，然后再通過taobao.trade.fullinfo.get獲取訂單詳情。

n  由于賣家三個月訂單量比較大，建議把三個月的訂單切分成按天獲取，減少單次請求對淘寶數(shù)據(jù)庫的記錄掃描量，以提升效率。

M  taobao.trades.sold.increment.get獲取增量訂單

n  采用入?yún)se_has_next=true的分頁方式可以避免每次API請求時對淘寶數(shù)據(jù)庫產(chǎn)生的count(*)，從而顯著提升速度和穩(wěn)定性。

n  由于獲取增量訂單接口是用修改時間過濾的，而修改時間是可變的，所以需要從后往前翻頁才能避免漏單。從后往前翻頁必須要知道最后一頁，所以必須在首次API請求時采用use_has_next=false方式統(tǒng)計訂單總數(shù)，計算出總頁數(shù)，然后再設(shè)置use_has_next=true終止訂單統(tǒng)計，從后往前翻頁。

n  如果接口返回的字段無法滿足應(yīng)用的需要，則強(qiáng)烈建議只獲取fields=tid這一個字段，然后再通過taobao.trade.fullinfo.get獲取訂單詳情。

M  使用taobao.trades.sold.get/taobao.trades.sold.increment.get只獲取tid字段時，建議設(shè)置page_size為最大值，減少API請求次數(shù)，提升效率。獲取多個字段時可根據(jù)自身的網(wǎng)絡(luò)情況設(shè)置page_size，建議設(shè)置為50左右。

異常處理：

M  同步訂單一般會采用多線程處理，由于API請求對APP是有頻率限制的，所以設(shè)置線程池大小時，需要根據(jù)TOP允許的API調(diào)用頻率來設(shè)置，避免限流后導(dǎo)致應(yīng)用長時間無法調(diào)用API。

M  對于API返回的ISP類型的錯誤或網(wǎng)絡(luò)連接錯誤，應(yīng)用線程應(yīng)該在休眠片刻中自動重試。而對于API返回的ISV類型的錯誤，應(yīng)用需要記錄日志以便日后排查，同時不要重試。

FAQ

• 關(guān)于此文檔暫時還沒有FAQ