項目需求：
需求很簡單，就是想獲取淘寶的訂單；
獲取淘寶訂單的幾種方式：
聚石塔：
首先是該商家必須已經入駐了聚石塔，因為聚石塔可以共享改商家的淘寶、天貓、阿里雲、支付寶等信息。所以你可以通過該商家的聚石塔賬號來調取訂單信息。
實現難度:★★
使用率：★★
因為只要有商家的聚石塔賬號，就可以讓商家給你提供API接口，去調用該商家的淘寶，天貓訂單信息，所以實現難度不大，但是使用率很低。因為入駐聚石塔的商家基本上都是大商家，而且入駐聚石塔的條件也比較苛刻。
物流寶：
taobao.logistics.orders.detail.get (批量查詢物流訂單,返回詳細信息)
前提是你 接入的商家必須要使用物流寶的物流來發貨，而且獲取的訂單信息，也是已經發貨了的訂單。所以感覺通過物流寶獲取訂單信息意義不大。
實現難度:★
使用率：★
WMS倉儲系統：
通過申請淘寶的WMS倉儲系統，然后和奇門進行對接，可以獲取訂單信息。但是此訂單信息是通過ERP發送過來的，也就是說該商家已經使用了ERP，並且ERP也已經獲取到了訂單信息。這個感覺最扯淡，我本來就是想獲取訂單信息，然后還要和ERP對接。而且ERP如果沒有獲取訂單信息怎么辦，那問題不又回到了原點。而且聯調起來是三方聯調，我感覺難度非常大。
實現難度:★★★★
使用率：★
訂單系統：
這個是使用最多的，也是最普遍的獲取訂單信息的方式
實現難度:★★★
使用率：★★★★
下面將要詳細介紹,下面這篇文章寫的很詳細了，是我轉載的：
http://www.iitshare.com/taobao-shop-orders-synchronization.html
項目背景
最近做一個電子商務平台的投標工作，寫技術標過程中，碰到需要和淘寶集成的接口，其中有一個需求就是需要將目前ERP系統中的訂單和淘寶店鋪中訂單進行同步，具體需求如下描述：
1、零售、批銷、代銷、機構訂單都存儲在客戶的ERP系統當中；
2、淘寶商城的訂單存儲在淘寶中，ERP系統中不存在；
3、目前投標的電子商務平台中商品訂單付款成功后需要將訂單轉入到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. 增量獲取則是把淘寶發生了變更的訂單同步回來，這個一般需要較短的時間。
下面的方案都會圍繞着如何初始化和增量獲取來講。
方案一
同步流程：
核心步驟：
1、三個月數據：通過taobao.trades.sold.get獲取3個月內到現在創建的訂單ID，再通過taobao.trade.fullinfo.get獲取訂單詳情
2、增量數據：通過taobao.trades.sold.increment.get獲取從現在開始的增量訂單ID，再通過taobao.trade.fullinfo.get獲取訂單詳情
適用范圍：
適用於ISV測試訂單同步功能或生產環境的中小賣家進行訂單同步。此方案比較低效，除非老的應用更新成本很高，否則不推薦大家使用，建議采用下面的方案。
方案二
同步流程：
核心步驟：
1、三個月數據：通過taobao.topats.trades.sold.get異步獲取3個月內到昨天23:59:59創建的訂單詳情
2、增量數據：通過taobao.trades.sold.increment.get獲取從今天00:00:00開始的增量訂單ID，再通過taobao.trade.fullinfo.get獲取訂單詳情。
適用范圍：
適用於所有類型的賣家，尤其是大賣家采用此方案可以極大的提高同步速度，對於超大型的賣家（如直充、金冠級別的賣家）也能很好的支持。
方案三
同步流程：
核心步驟：
1、三個月數據：
a) 首先，通過taobao.topats.trades.sold.get異步獲取3個月內到昨天23:59:59創建的訂單詳情
b) 然后，通過taobao.trades.sold.increment.get獲取從今天00:00:00到現在的增量訂單ID，再通過taobao.trade.fullinfo.get獲取訂單詳情
2、增量數據：通過主動通知客戶端實時監聽訂單變更消息，再通過taobao.trade.fullinfo.get獲取訂單詳情
適用范圍：
適用於所有類型的賣家，是所有方案中相對復雜，但效率最高的方案，推薦所有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類型的錯誤，應用需要記錄日志以便日后排查，同時不要重試