订单同步有技巧,双十一高峰不再怕

  • 时间:
  • 浏览:2
  • 来源:uu直播快3平台_UU快3直播官方

第有一八个是实时同步流程,主要应用于自动发货等实时除理的场景。淘宝开放平台提供了主动通知的消息服务能力。接收到订单变更的实时消息后会,通过订单详情接口,就还需要拿到订单详情更新本地数据。

传统的订单同步最好的方法主要分为有一八个流程。

数据推送的设计要点包括:

如上图所示,最上层是SDK,其作用是把各种API的请求进行合并,路由到相应的服务去进行调用。第二层是异地多活,SDK还需要根据就近原则调用到相应的机房。第三层是TOP网关平台,有一八个请求进来后会会做API的校验、安全、流控等规则的校验等,校验通后会才会把API进行拆分,有一八个批量API请求拆分成N个API请求,某些把请求提交到后台相应的提供服务能力的机器上,等待时间后台服务除理完后会通过NIO的网络事件回来唤醒工作多系统进程 ,工作多系统进程 会把后端返回的结果进行数据的转换包括安全过滤、日志打点等,直到所有请求除理完后会会进行API的分派、排序、合并、导出,最后把请求唤醒返回给客户端的SDK。整个服务端在除理批量API的过程中,采用了全异步化的除理,不管一次发起几个次API请求,就有会影响服务端的稳定性和强度,这是批量API区别于TQL和ATS最根本的地方。

单个API的调用最好的方法比较熟悉,比如调用订单详情API,首先创建淘宝的客户端,某些新建调用订单详情的request,设置要查询的订单字段,每个请求执行一次request。批量API引入TaobaoBatchRequest的对象,不用每次请求都加进相同的字段,只需要去新建不同的request,追加到batch request中,最后只发起一次API调用即可。批量API调用与串行API调用比较发现,批量API调用和单次API调用时间接近,远比串行API调用强度高。

上边表+大字段:数据库上采用上边表和大字段的设计,适配各种ISV的个性化字段推送需求;

订单同步服务产生的背景是漏单除理成本高、API轮询实时性不高、大卖家数据难同步,该服务的定位是面向公网的数据同步服务,做到把阿里内部的数据库通过订单同步服务数据推送不用还还可以实时可靠的推送到ISV数据库。目前将会做到了一致性(数据完整性一致,严密单)、高实时(秒级完成数据同步)、通用化(千人千面,自助接入和开通)、可伸缩(可横向扩展、支持亿级数据同步)。

本文根据顾风胜在大流量高并发互联网应用实践在线峰会上题为《海量订单实时同步与除理实践》的分享分派而成。

独享RDS+就近访问:RDS是各应用独享的,访问频率和性能由ISV本人控制,不用像API那样受他人的影响。整个RDS和数据推送客户端是中放同時 的,数据推送还需要就近访问,同步强度更高。

订单同步API:

分组隔离+双机房容灾:数据推送客户端采用了分组隔离的最好的方法,为每有一八个分组合适分配两台以上的机器,某些分到不同的机房,即使其中有一八个机房宕机了,本来会影响数据的正常推送,某些隔离各应用之间的影响;

除了聚石塔内的API调用以外,某些商家会在移动端将会办公网络中调用API,比如在千牛插件上边调用API,此时的强度一般很差,将会在弱网环境下,每次API请求的TCP的三次握手建立连接时长更高,每次API调用总体时长比在聚石塔上边调用要高什么都。后会开放平台也提供了并是不是批量API调用最好的方法来除理并是不是问題:有一八个是TQL,但TQL调用最好的方法,不易理解,串行调用,安全隐患高;另外有一八个是ATS,但ATS提供成本高,使用复杂化,实时性差。批量API还需要做到高性能、低延迟、通用化、容易使用。

如上图所示,整个数据推送的架构分为两累积:部署在阿里内网的数据推送的服务端、淘宝开放平台的API服务和消息服务;在聚石塔内部署的数据推送的客户端、ISV应用服务器以及ISV的RDS。

直播视频:点此进入

对于ERP与WMS的互通,ISV后会更多的是通过自研发进行对接,需要双方沟通接口标准,制定对接计划,联调测试等,对接的成本高,周期长,重复对接。针对哪几种问題,淘宝开放平台推出了奇门,为商家ERP与WMS提供标准化的对接。从图中还需要看出,后会ERP和WMS对接的整个行态是有一八个网状的行态,有一八个ERP需要和所有的WMS进行对接,反之亦然,是有一八个N对N的情况。奇门引入了数据总线的概念,把ERP和WMS之间对接的数据交互的场景进行标准化,形成数据总线,曾经的好处是ERP只需要和奇门数据总线进行对接就还需要实现任意WMS的对接,反之亦然,是有一八个N对1的情况。

从图中还需要看出,整个双十一订单除理过程中主要涉及到有一八个系统:平台(天猫、淘宝)、ERP/OMS(用来除理订单)、WMS(仓库内的打包、发货)。其中包括了八个情况:拉单还需要平台提供的订单API来完成,ERP/OMS进行转单、审单、打单,WMS提供拣货、打包、发货,最后会把情况进行回写。订单回写完成后会,订单情况就会在淘宝订单的物流详情中显示出来。

针对双十一订单的整个链路,接下来主要给亲戚亲戚让让我们 歌词 推荐平台提供的几个产品,让订单同步和除理更加高效:订单同步通过数据推送(订单同步服务)、面单打印通过菜鸟电子面单、仓库对接通过奇门数据总线,订单情况回写通过批量API。

针对上述订单遗漏情况,淘宝推出了订单同步服务。

上边表分为关键字段、系统字段和大字段。关键字段是订单上边比较重要的字段,比如交易ID、交易情况、交易类型等。系统字段是用于整个数据推送在进行订单的增、删、改、查以及对单时所用到的字段。大字段是订单详情API返回的整个JSON字符串,可任意定制需要返回的字段。 

单个API的协议通过签名、头部参数的设置、业务参数的拼装实现有一八个API的调用。批量API的协议和单个API协议的区别比较小,唯一的区别是body上边的参数,引入了有一八个公共参数,还需要中放公共字段中除理重复传送,减少网络开销。不同API的参数中放子参数列表中,某些通过-s-的分隔符分开。

PDF下载:点此进入

打单面单API:

第八个是增量同步流程。订单在不断的产生和变化,需要在后台定时同步增量的订单,什么都应该在后台定时起某些异步的多系统进程 去同步并是不是应用里所有已授权用户的增量订单,某些通过订单详情接口获取订单详情,某些把最后的同步时间点存储起来以便下次使用。

通过这有一八个流程,亲戚亲戚让让我们 歌词 还需要组合出什么都方案。第并是不是是“全量+增量”的方案,还需要实现订单的初始化、增量同步,适用于大累积的业务场景;第二种是“全量+实时”的方案,占据 的问題是累积订单的变更将会这样发消息,适用于对数据准确性要求就有非常高的实时订单除理场景;第并是不是是“全量+实时+对单”的方案,还需要保证整个订单同步的实时可靠,适用于对数据准确性和实时性要求极高的场景。

图中是淘宝天猫交易的机房分布,其分为中心机房和单元机房。中心机房放着买家库的主库,单元机房也会同样放买家库的主库。消费者下单后,订单会直接落入买家库上边,中心机房和单元机房会通过DRC进行双向数据同步,同時 在买家库的基础上同步出了卖家库用来查询已卖出的宝贝,在卖家库基础上同步出了卖家库的备库,而并是不是备库才是真正对外提供交易批量API的库。交易批量API直接查询的是卖家库的备库,而交易详情API是关联的买家库。买家库是有一八个实时的库,而卖家库是由买家库同步过来的。卖家库主库与备库之间在高压情况下(双十一)会再次出现同步延迟是是因为批量查询订单遗漏。并是不是情况下的漏单是非常难以除理的,比较粗暴的做法是每天夜深 全量对昨天的订单再进行一次同步,但代价很高。

taobao.trades.sold.get(获取有一八个月内已卖出的订单):使用use_has_next=true的最好的方法分页,每次分页还需要减少一次db count,提高API分页查询的强度;对于订单量大的卖家,需要切分时间段,比如按天获取,双十一峰值六时 甚至切分到按分钟获取;需要调用taobao.trade.fullinfo.get获取详情的情况下,批量接口设置fields=tid还需要直接走DB索引,获得更高的强度。

可靠消息+对单补单:通过可靠的消息服务保证订单实时推送到RDS上边;通过增量API、大数据、ODPS进行对单补单,确保订单情况与淘宝完整性一致;

第有一八个流程是初始化流程,新的用户进来后会需要给其授权,某些后台需要异步启动有一八个新的多系统进程 把订单同步回来,一般最多同步有一八个月内已卖出的订单,此外还需要调用订单详情接口获取单笔订单详情。

批量插入+更新优先:订单RDS采用批量插入,提高写入强度,订单占据 变更后,采用更新优先,除理每次更新就有先查询一次DB,减少对DB的查询次数;

兼容API请求结果:存储到RDS上边的数据是兼容API请求的JSON返回格式,还需要使用TOP提供的SDK直接解释成交易对象;

taobao.trades.sold.increment.get(增量获取变更的订单):不还还可以曾经往后翻页,某些已翻页的订单占据 变化,会是是因为后续页数的订单前移,前移订单将会遗漏,正确的做法是从后往前翻页;首次请求使用use_has_next=false获取变更总数,后续请求通过use_has_next=true分页,每次分页还需要减少一次db count;需要调用taobao.trade.fullinfo.get获取详情的情况下,批量接口设置fields=tid还需要直接走DB索引,获得更高的强度。

批量API的几个特点:Payload以form的形式去承载每个API,默认以\r\n-S-\r\n进行分割(也支持自定义分隔符);第一行#PUBLIC#刚结束,可提取公共参数和API名称;参数优先级:子API参数 ===覆盖===> #PUBLIC#参数 ===覆盖===> URL参数;签名最好的方法,基于rest签名:byte2hex (hmac(key1value1key2value2...payloadsecret))。