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

  • 时间:
  • 浏览:0
  • 来源:5分11选5官方_大发5分3D

独享RDS+就近访问:RDS是各应用独享的,访问频率和性能由ISV买车人控制,太多像API那样受他人的影响。整个RDS和数据推送客户端是倒入同时的,数据推送并里能 就近访问,同步速率更高。

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

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

通过许多个流程,亲戚亲戚亲们并里能 组合出什么都有 方案。第某种是“全量+增量”的方案,并里能 实现订单的初始化、增量同步,适用于大部分的业务场景;第二种是“全量+实时”的方案,占据 的问题报告 是部分订单的变更肯并能并能 发消息,适用于对数据准确性要求都是非常高的实时订单正确处理场景;第某种是“全量+实时+对单”的方案,并里能 保证整个订单同步的实时可靠,适用于对数据准确性和实时性要求极高的场景。

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

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

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

如上图所示,最上层是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的个性化字段推送需求;

批量插入+更新优先:订单RDS采用批量插入,提高写入速率,订单占据 变更后,采用更新优先,正确处理每次更新都是先查询一次DB,减少对DB的查询次数;

taobao.trades.sold.increment.get(增量获取变更的订单):并能 原先往后翻页,而且已翻页的订单占据 变化,会原因分析分析分析后续页数的订单前移,前移订单肯能遗漏,正确的做法是从后往前翻页;首次请求使用use_has_next=false获取变更总数,后续请求通过use_has_next=true分页,每次分页并里能 减少一次db count;时要调用taobao.trade.fullinfo.get获取详情的情況下,批量接口设置fields=tid并里能 直接走DB索引,获得更高的速率。

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

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

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

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

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

可靠消息+对单补单:通过可靠的消息服务保证订单实时推送到RDS中间;通过增量API、大数据、ODPS进行对单补单,确保订单情況与淘宝详细一致;

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

分组隔离+双机房容灾:数据推送客户端采用了分组隔离的方法,为每一个分组离米 分配两台以上的机器,而且分到不同的机房,即使其中一个机房宕机了,什么都有 会影响数据的正常推送,而且隔离各应用之间的影响;

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

PDF下载:点此进入

订单同步API:

直播视频:点此进入

从图中并里能 看出,整个双十一订单正确处理过程中主要涉及到一个系统:平台(天猫、淘宝)、ERP/OMS(用来正确处理订单)、WMS(仓库内的打包、发货)。其中包括了三个白情況:拉单并里能 平台提供的订单API来完成,ERP/OMS进行转单、审单、打单,WMS提供拣货、打包、发货,最不会把情況进行回写。订单回写完成以前,订单情況就会在淘宝订单的物流详情中显示出来。

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

单个API的协议通过签名、头部参数的设置、业务参数的拼装实现一个API的调用。批量API的协议和单个API协议的区别比较小,唯一的区别是body中间的参数,引入了一个公共参数,并里能 倒入公共字段中正确处理重复传送,减少网络开销。不同API的参数倒入子参数列表中,而且通过-s-的分隔符分开。

兼容API请求结果:存储到RDS中间的数据是兼容API请求的JSON返回格式,并里能 使用TOP提供的SDK直接解释成交易对象;

打单面单API:

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

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

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