背景
订 单是卖家的核心数据，卖家的很多日常工作都是围绕着订单展开，应用的基本功能就是要保证订单实时、完整的展示在卖家面前。由于API请求依赖于网络，存在 着网络不稳定和同步时间长的问题，所以应用必须把淘宝的订单数据同步到本地。如何才能快速、完整的把订单同步到本地是本方案将要讨论的问题。
名词解释
在线订单：卖家三个月内已卖出的订单。
增量订单：相对已经同步到本地的订单，凡是在淘宝上发生了变更的订单就是增量订单。
消息服务：一种通过HTTP长连接实时向客户端（应用）推送数据（交易）变更的渠道。
API介绍
taobao.trades.sold.get - 获取三个月内已卖出的在线订单，适用于用户初始化的时候使用，ISV不应该用此接口来获取增量订单。不建议使用或尽量少用此接口。
taobao.trades.sold.increment.get – 获取增量订单，适用于用户初始化后，增量同步发生变更的订单，ISV不应该用此接口来获取三个月内的订单。
taobao.trade.fullinfo.get - 获取单笔订单详情。
实施方案
订单同步主要分为初始化和增量获取两个步骤：
1. 初始化是把3个月内的在线订单全部同步回来，这个需要较长的时间；
2. 增量获取则是把淘宝发生了变更的订单同步回来，这个一般需要较短的时间。
下面的方案都会围绕着如何初始化和增量获取来讲。
同步流程：
核心步骤：
u 三个月数据：通过taobao.trades.sold.get获取3个月内到现在创建的订单ID，再通过taobao.trade.fullinfo.get获取订单详情
u 增量数据：通过taobao.trades.sold.increment.get获取从现在开始的增量订单ID，再通过taobao.trade.fullinfo.get获取订单详情
适用范围：
适用于ISV测试订单同步功能或生产环境的中小卖家进行订单同步。此方案比较低效，除非老的应用更新成本很高，否则不推荐大家使用，建议采用下面的方案。
方案二
同步流程：
核心步骤：
u 三个月数据：
a) 首先，通过taobao.trades.sold.get获取3个月内到昨天23:59:59创建的订单详情
b) 然后，通过taobao.trades.sold.increment.get获取从今天00:00:00到现在的增量订单ID，再通过taobao.trade.fullinfo.get获取订单详情
u 增量数据：通过消息服务客户端实时监听订单变更消息，再通过taobao.trade.fullinfo.get获取订单详情
适用范围：
适用于所有类型的卖家，是所有方案中相对复杂，但效率最高的方案，推荐所有ISV采用。
经验分享
漏单问题：
M 通过taobao.trades.sold.get和taobao.trades.sold.increment.get获取订单时，交易类型type入参默认只查询部分类型的订单，要查询所有类型的订单，必须显式提供所有交易类型作为type入参。
M 通过taobao.trades.sold.increment.get获取增量订单时，返回结果是按订单修改时间倒序排序的，分页必须从后往前翻，防止正向翻页过程中订单发生变更而导致漏单。
M 通过taobao.trades.sold.increment.get获取增量订单时，每次获取的起始时间适当前移10分钟左右（双11大促时建议前移30分钟左右），防止极端情况下由于淘宝系统压力而导致订单延迟更新到数据库而产生的漏单。
M 通过主动通知接收订单变更消息时，需要处理服务器重启或网络断开连接而导致的消息丢失问题，详细内容请查看消息服务。
性能问题：
M taobao.trades.sold.get获取三个月已卖家的订单
n 采用入参use_has_next=true的分页方式可以避免每次API请求对淘宝数据库产生的count(*)，从而显著提升速度和稳定性。
n 由于获取三个月内的订单接口是用创建时间过滤的，而创建时间是不可变的，所以从前往后翻页也不会导致漏单，因而可以省掉第一步的count(*)，而直接采用入参use_has_next=true的方式分页获取，直到返回结果中has_next=false时终止翻页。
n 如果接口返回的字段无法满足应用的需要，则强烈建议只获取fields=tid这一个字段，然后再通过taobao.trade.fullinfo.get获取订单详情。
n 由于卖家三个月订单量比较大，建议把三个月的订单切分成按天获取，减少单次请求对淘宝数据库的记录扫描量，以提升效率。
M taobao.trades.sold.increment.get获取增量订单
n 采用入参use_has_next=true的分页方式可以避免每次API请求时对淘宝数据库产生的count(*)，从而显著提升速度和稳定性。
n 由 于获取增量订单接口是用修改时间过滤的，而修改时间是可变的，所以需要从后往前翻页才能避免漏单。从后往前翻页必须要知道最后一页，所以必须在首次API 请求时采用use_has_next=false方式统计订单总数，计算出总页数，然后再设置use_has_next=true终止订单统计，从后往前 翻页。
n 如果接口返回的字段无法满足应用的需要，则强烈建议只获取fields=tid这一个字段，然后再通过taobao.trade.fullinfo.get获取订单详情。
M 使 用taobao.trades.sold.get/taobao.trades.sold.increment.get只获取tid字段时，建议设置 page_size为最大值，减少API请求次数，提升效率。获取多个字段时可根据自身的网络情况设置page_size，建议设置为50左右。
异常处理：
M 同步订单一般会采用多线程处理，由于API请求对APP是有频率限制的，所以设置线程池大小时，需要根据TOP允许的API调用频率来设置，避免限流后导致应用长时间无法调用API。
M 对于API返回的ISP类型的错误或网络连接错误，应用线程应该在休眠片刻中自动重试。而对于API返回的ISV类型的错误，应用需要记录日志以便日后排查，同时不要重试。