獲取淘寶訂單的解決方案
阿新 • • 發佈：2019-01-09
漏單問題：
1、通過taobao.trades.sold.get和taobao.trades.sold.increment.get獲取訂單時，交易型別type入參預設只查詢部分型別的訂單，要查詢所有型別的訂單，必須顯式提供所有交易型別作為type入參。
2、通過taobao.trades.sold.increment.get獲取增量訂單時，返回結果是按訂單修改時間倒序排序的，分頁必須從後往前翻，防止正向翻頁過程中訂單發生變更而導致漏單。
3、通過taobao.trades.sold.increment.get獲取增量訂單時，每次獲取的起始時間適當前移10分鐘左右（雙11大促時建議前移30分鐘左右），防止極端情況下由於淘寶系統壓力而導致訂單延遲更新到資料庫而產生的漏單。
4、通過主動通知接收訂單變更訊息時，需要處理伺服器重啟或網路斷開連線而導致的訊息丟失問題，詳細內容請檢視主動通知文件。
效能問題
1、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) 由於賣家三個月訂單量比較大，建議把三個月的訂單切分成按天獲取，減少單次請求對淘寶資料庫的記錄掃描量，以提升效率。
2、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獲取訂單詳情。
3、使用taobao.trades.sold.get/taobao.trades.sold.increment.get只獲取tid欄位時，建議設定page_size為最大值，減少API請求次數，提升效率。獲取多個欄位時可根據自身的網路情況設定page_size，建議設定為50左右。
異常處理
1、同步訂單一般會採用多執行緒處理，由於API請求對APP是有頻率限制的，所以設定執行緒池大小時，需要根據TOP允許的API呼叫頻率來設定，避免限流後導致應用長時間無法呼叫API。
2、對於API返回的ISP型別的錯誤或網路連線錯誤，應用執行緒應該在休眠片刻中自動重試。而對於API返回的ISV型別的錯誤，應用需要記錄日誌以便日後排查，同時不要重試
1、通過taobao.trades.sold.get和taobao.trades.sold.increment.get獲取訂單時，交易型別type入參預設只查詢部分型別的訂單，要查詢所有型別的訂單，必須顯式提供所有交易型別作為type入參。
2、通過taobao.trades.sold.increment.get獲取增量訂單時，返回結果是按訂單修改時間倒序排序的，分頁必須從後往前翻，防止正向翻頁過程中訂單發生變更而導致漏單。
3、通過taobao.trades.sold.increment.get獲取增量訂單時，每次獲取的起始時間適當前移10分鐘左右（雙11大促時建議前移30分鐘左右），防止極端情況下由於淘寶系統壓力而導致訂單延遲更新到資料庫而產生的漏單。
4、通過主動通知接收訂單變更訊息時，需要處理伺服器重啟或網路斷開連線而導致的訊息丟失問題，詳細內容請檢視主動通知文件。
效能問題
1、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) 由於賣家三個月訂單量比較大，建議把三個月的訂單切分成按天獲取，減少單次請求對淘寶資料庫的記錄掃描量，以提升效率。
2、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獲取訂單詳情。
3、使用taobao.trades.sold.get/taobao.trades.sold.increment.get只獲取tid欄位時，建議設定page_size為最大值，減少API請求次數，提升效率。獲取多個欄位時可根據自身的網路情況設定page_size，建議設定為50左右。
異常處理
1、同步訂單一般會採用多執行緒處理，由於API請求對APP是有頻率限制的，所以設定執行緒池大小時，需要根據TOP允許的API呼叫頻率來設定，避免限流後導致應用長時間無法呼叫API。
2、對於API返回的ISP型別的錯誤或網路連線錯誤，應用執行緒應該在休眠片刻中自動重試。而對於API返回的ISV型別的錯誤，應用需要記錄日誌以便日後排查，同時不要重試