项目需求:

需求很简单,就是想获取淘宝的订单;

获取淘宝订单的几种方式:

聚石塔:

首先是该商家必须已经入驻了聚石塔,因为聚石塔可以共享改商家的淘宝、天猫、阿里云、支付宝等信息。所以你可以通过该商家的聚石塔账号来调取订单信息。

实现难度:★★

使用率:★★

因为只要有商家的聚石塔账号,就可以让商家给你提供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类型的错误,应用需要记录日志以便日后排查,同时不要重试

taobao.logistics.orders.detail.get (批量查询物流订单,返回详细信息)
 
https://www.cnblogs.com/siqianyu/p/6221684.html