訂單同步
背景
訂單是賣家的核心數(shù)據(jù)，賣家的很多日常工作都是圍繞著訂單展開，應(yīng)用的基本功能就是要保證訂單實(shí)時(shí)、完整的展示在賣家面前。由于API請(qǐng)求依賴于網(wǎng)絡(luò)，存在著網(wǎng)絡(luò)不穩(wěn)定和同步時(shí)間長(zhǎng)的問(wèn)題，所以應(yīng)用必須把淘寶的訂單數(shù)據(jù)同步到本地。如何才能快速、完整的把訂單同步到本地是本方案將要討論的問(wèn)題。
訂單同步有兩種方式：1、通過(guò)api 同步 2、基于rds訂單同步服務(wù) 。本文主要分析使用api 同步訂單的場(chǎng)景，有關(guān)rds訂單同步使用方法，可參考 //open.taobao.com/docs/doc.htm.htm?articleId=101587&docType=1&treeId=2
名詞解釋
在線訂單：賣家三個(gè)月內(nèi)已賣出的訂單。
增量訂單：相對(duì)已經(jīng)同步到本地的訂單，凡是在淘寶上發(fā)生了變更的訂單就是增量訂單。
消息服務(wù)：一種通過(guò)HTTP長(zhǎng)連接實(shí)時(shí)向客戶端（應(yīng)用）推送數(shù)據(jù)（交易）變更的渠道。
API介紹
taobao.trades.sold.get - 獲取三個(gè)月內(nèi)已賣出的在線訂單，適用于用戶初始化的時(shí)候使用，ISV不應(yīng)該用此接口來(lái)獲取增量訂單。不建議使用或盡量少用此接口。
taobao.trades.sold.increment.get – 獲取增量訂單，適用于用戶初始化后，增量同步發(fā)生變更的訂單，ISV不應(yīng)該用此接口來(lái)獲取三個(gè)月內(nèi)的訂單。
taobao.trade.fullinfo.get - 獲取單筆訂單詳情。
實(shí)施方案
訂單同步主要分為初始化和增量獲取兩個(gè)步驟：
1. 初始化是把3個(gè)月內(nèi)的在線訂單全部同步回來(lái)，這個(gè)需要較長(zhǎng)的時(shí)間；
2. 增量獲取則是把淘寶發(fā)生了變更的訂單同步回來(lái)，這個(gè)一般需要較短的時(shí)間。
下面的方案都會(huì)圍繞著如何初始化和增量獲取來(lái)講。
方案一
同步流程：
核心步驟：
u 三個(gè)月數(shù)據(jù)：通過(guò)taobao.trades.sold.get獲取3個(gè)月內(nèi)到現(xiàn)在創(chuàng)建的訂單ID，再通過(guò)taobao.trade.fullinfo.get獲取訂單詳情
u 增量數(shù)據(jù)：通過(guò)taobao.trades.sold.increment.get獲取從現(xiàn)在開始的增量訂單ID，再通過(guò)taobao.trade.fullinfo.get獲取訂單詳情
適用范圍：
適用于ISV測(cè)試訂單同步功能或生產(chǎn)環(huán)境的中小賣家進(jìn)行訂單同步。此方案比較低效，除非老的應(yīng)用更新成本很高，否則不推薦大家使用，建議采用下面的方案。
方案二
同步流程：
核心步驟：
a) 首先，通過(guò)taobao.trades.sold.get獲取3個(gè)月內(nèi)到昨天23:59:59創(chuàng)建的訂單詳情
u 三個(gè)月數(shù)據(jù)：
b) 然后，通過(guò)taobao.trades.sold.increment.get獲取從今天00:00:00到現(xiàn)在的增量訂單ID，再通過(guò)taobao.trade.fullinfo.get獲取訂單詳情
u 增量數(shù)據(jù)：通過(guò)消息服務(wù)客戶端實(shí)時(shí)監(jiān)聽訂單變更消息，再通過(guò)taobao.trade.fullinfo.get獲取訂單詳情
適用范圍：
適用于所有類型的賣家，是所有方案中相對(duì)復(fù)雜，但效率最高的方案，推薦所有ISV采用。
經(jīng)驗(yàn)分享
漏單問(wèn)題：
M 通過(guò)taobao.trades.sold.get和taobao.trades.sold.increment.get獲取訂單時(shí)，交易類型type入?yún)⒛J(rèn)只查詢部分類型的訂單，要查詢所有類型的訂單，必須顯式提供所有交易類型作為type入?yún)ⅰ?/span>
M 通過(guò)taobao.trades.sold.increment.get獲取增量訂單時(shí)，返回結(jié)果是按訂單修改時(shí)間倒序排序的，分頁(yè)必須從后往前翻，防止正向翻頁(yè)過(guò)程中訂單發(fā)生變更而導(dǎo)致漏單。
M 通過(guò)taobao.trades.sold.increment.get獲取增量訂單時(shí)，每次獲取的起始時(shí)間適當(dāng)前移10分鐘左右（雙11大促時(shí)建議前移30分鐘左右），防止極端情況下由于淘寶系統(tǒng)壓力而導(dǎo)致訂單延遲更新到數(shù)據(jù)庫(kù)而產(chǎn)生的漏單。
M 通過(guò)主動(dòng)通知接收訂單變更消息時(shí)，需要處理服務(wù)器重啟或網(wǎng)絡(luò)斷開連接而導(dǎo)致的消息丟失問(wèn)題，詳細(xì)內(nèi)容請(qǐng)查看消息服務(wù)。
性能問(wèn)題：
M taobao.trades.sold.get獲取三個(gè)月已賣家的訂單
n 采用入?yún)se_has_next=true的分頁(yè)方式可以避免每次API請(qǐng)求對(duì)淘寶數(shù)據(jù)庫(kù)產(chǎn)生的count(*)，從而顯著提升速度和穩(wěn)定性。
n 由于獲取三個(gè)月內(nèi)的訂單接口是用創(chuàng)建時(shí)間過(guò)濾的，而創(chuàng)建時(shí)間是不可變的，所以從前往后翻頁(yè)也不會(huì)導(dǎo)致漏單，因而可以省掉第一步的count(*)，而直接采用入?yún)se_has_next=true的方式分頁(yè)獲取，直到返回結(jié)果中has_next=false時(shí)終止翻頁(yè)。
n 如果接口返回的字段無(wú)法滿足應(yīng)用的需要，則強(qiáng)烈建議只獲取fields=tid這一個(gè)字段，然后再通過(guò)taobao.trade.fullinfo.get獲取訂單詳情。
n 由于賣家三個(gè)月訂單量比較大，建議把三個(gè)月的訂單切分成按天獲取，減少單次請(qǐng)求對(duì)淘寶數(shù)據(jù)庫(kù)的記錄掃描量，以提升效率。
M taobao.trades.sold.increment.get獲取增量訂單
n 采用入?yún)se_has_next=true的分頁(yè)方式可以避免每次API請(qǐng)求時(shí)對(duì)淘寶數(shù)據(jù)庫(kù)產(chǎn)生的count(*)，從而顯著提升速度和穩(wěn)定性。
n 由于獲取增量訂單接口是用修改時(shí)間過(guò)濾的，而修改時(shí)間是可變的，所以需要從后往前翻頁(yè)才能避免漏單。從后往前翻頁(yè)必須要知道最后一頁(yè)，所以必須在首次API請(qǐng)求時(shí)采用use_has_next=false方式統(tǒng)計(jì)訂單總數(shù)，計(jì)算出總頁(yè)數(shù)，然后再設(shè)置use_has_next=true終止訂單統(tǒng)計(jì)，從后往前翻頁(yè)。
n 如果接口返回的字段無(wú)法滿足應(yīng)用的需要，則強(qiáng)烈建議只獲取fields=tid這一個(gè)字段，然后再通過(guò)taobao.trade.fullinfo.get獲取訂單詳情。
M 使用taobao.trades.sold.get/taobao.trades.sold.increment.get只獲取tid字段時(shí)，建議設(shè)置page_size為最大值，減少API請(qǐng)求次數(shù)，提升效率。獲取多個(gè)字段時(shí)可根據(jù)自身的網(wǎng)絡(luò)情況設(shè)置page_size，建議設(shè)置為50左右。
異常處理：
M 同步訂單一般會(huì)采用多線程處理，由于API請(qǐng)求對(duì)APP是有頻率限制的，所以設(shè)置線程池大小時(shí)，需要根據(jù)TOP允許的API調(diào)用頻率來(lái)設(shè)置，避免限流后導(dǎo)致應(yīng)用長(zhǎng)時(shí)間無(wú)法調(diào)用API。
M 對(duì)于API返回的ISP類型的錯(cuò)誤或網(wǎng)絡(luò)連接錯(cuò)誤，應(yīng)用線程應(yīng)該在休眠片刻中自動(dòng)重試。而對(duì)于API返回的ISV類型的錯(cuò)誤，應(yīng)用需要記錄日志以便日后排查，同時(shí)不要重試。
FAQ
- 關(guān)于此文檔暫時(shí)還沒(méi)有FAQ