背景

订单是卖家的核心数据，卖家的很多日常工作都是围绕着订单展开，应用的基本功能就是要保证订单实时、完整的展示在卖家面前。由于API请求依赖于网络，存在着网络不稳定和同步时间长的问题，所以应用必须把速卖通的订单数据同步到本地。如何才能快速、完整的把订单同步到本地是本方案将要讨论的问题。
本文主要分析使用api 同步订单的场景。

名词解释

在线订单：卖家已卖出的订单。
增量订单：相对已经同步到本地的订单，凡是在速卖通上发生了变更的订单就是增量订单。
消息服务：一种通过HTTP长连接实时向客户端（应用）推送数据（交易）变更的渠道。

API介绍

aliexpress.trade.seller.orderlist.get- 获取订单列表，目前在线订单和增量订单都通过该接口来同步。
aliexpress.trade.new.redefining.findorderbyid- 获取单笔订单详情。

实施方案

订单同步主要分为初始化和增量获取两个步骤：
初始化是把所有的在线订单全部同步回来，这个需要较长的时间；
增量获取则是把速卖通发生了变更的订单同步回来，这个一般需要较短的时间。
下面的方案都会围绕着如何初始化和增量获取来讲。

方案一

同步流程：

核心步骤：

历史数据：通过aliexpress.trade.seller.orderlist.get 获取历史到现在创建的订单ID，再通过aliexpress.trade.new.redefining.findorderbyid获取订单详情
增量数据：通过aliexpress.trade.seller.orderlist.get 获取从现在开始的增量订单ID，再通过aliexpress.trade.new.redefining.findorderbyid获取订单详情

适用范围：

适用于ISV测试订单同步功能或生产环境的中小卖家进行订单同步。此方案比较低效，除非老的应用更新成本很高，否则不推荐大家使用，建议采用下面的方案。

方案二

同步流程：

核心步骤：

历史数据：通过aliexpress.trade.seller.orderlist.get 获取历史到现在的增量订单ID，再通过aliexpress.trade.new.redefining.findorderbyid获取订单详情
增量数据：通过消息服务客户端实时监听订单变更消息，再通过aliexpress.trade.new.redefining.findorderbyid获取订单详情

适用范围：

适用于所有类型的卖家，是所有方案中相对复杂，但效率最高的方案，推荐所有ISV采用。

经验分享

漏单问题：

通过aliexpress.trade.seller.orderlist.get获取订单时，订单状态order_status入参默认不查询已结束的订单，要查询已结束的订单，必须显式提供已结束状态作为order_status入参。
通过aliexpress.trade.seller.orderlist.get获取增量订单时，返回结果是按订单修改时间顺序排序的，为了防止翻页过程中订单发生变更而导致漏单,建议反向翻页，同时入参包含修改开始时间和修改结束时间。
通过aliexpress.trade.seller.orderlist.get获取增量订单时，每次获取的起始时间适当前移10分钟左右（双11大促时建议前移30分钟左右），防止极端情况下由于系统压力而导致订单延迟更新到数据库而产生的漏单。
通过主动通知接收订单变更消息时，需要处理服务器重启或网络断开连接而导致的消息丢失问题，详细内容请查看消息服务。

性能问题：

aliexpress.trade.seller.orderlist.get 获取卖家已结束的订单
必须显式提供已结束状态作为order_status入参，同时加上创建时间作为查询条件。请注意：如果要使用修改时间作为入参，必须加上创建时间，且创建开始时间和创建结束时间的范围不能超过30天（大促期间可能会缩小）。
由于卖家已结束的订单量比较大，建议把订单切分成按创建时间的天获取，减少单次请求对数据库的记录扫描量，以提升效率。
aliexpress.trade.seller.orderlist.get 获取增量订单（不包括已结束的订单）
建议显式指定order_status入参，同时加上修改时间作为查询条件，以减少数据库的记录扫描量。请注意：如果要使用修改时间作为入参，必须加上创建时间，且创建开始时间和创建结束时间的范围不能超过180天（大促期间可能会缩小）。

异常处理：

同步订单一般会采用多线程处理，由于API请求对APP是有频率限制的，所以设置线程池大小时，需要根据TOP允许的API调用频率来设置，避免限流后导致应用长时间无法调用API。
对于API返回的ISP类型的错误或网络连接错误，应用线程应该在休眠片刻中自动重试。而对于API返回的ISV类型的错误，应用需要记录日志以便日后排查，同时不要重试。

订单状态：

PLACE_ORDER_SUCCESS:等待买家付款;
IN_CANCEL:买家申请取消;
WAIT_SELLER_SEND_GOODS:等待您发货;
SELLER_PART_SEND_GOODS:部分发货;
WAIT_BUYER_ACCEPT_GOODS:等待买家收货;
FUND_PROCESSING:买卖家达成一致，资金处理中；
IN_ISSUE:含纠纷中的订单;
IN_FROZEN:冻结中的订单;
WAIT_SELLER_EXAMINE_MONEY:等待您确认金额;
PAYMENT_PROCESSING：支付处理中,目前只有延迟扣款场景
RISK_CONTROL:订单处于风控24小时中，从买家在线支付完成后开始，持续24小时。
以上状态查询可分别做单独查询，不传订单状态查询订单信息不包含（FINISH，已结束订单状态） FINISH:已结束的订单，需单独查询。

订单结束原因:

end_issue
trade_close
buyer_confirm_goods
buyer_confirm_goods_timeout
pay_timeout
buyer_cancel_order
risk_closed
suspicious_trade
confirm_payamount_timeout
reject_payamount
send_goods_timeout
buyer_cancel_notpay_order
buyer_cancel_order_in_risk
security_close

FAQ