首页 物流新闻 订单同步有技巧,双十一顶峰不再怕

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

直播视频: https://yq.aliyun.com/edu/lesson/169?spm=5176.100239.blogcont60887.6.Tk2oZZ PDF下载: h…

直播视频:
https://yq.aliyun.com/edu/lesson/169?spm=5176.100239.blogcont60887.6.Tk2oZZ
PDF下载:
https://yq.aliyun.com/attachment/download/?spm=5176.100239.blogcont60887.7.Tk2oZZfilename=dc0e8c7347845b6157a0e5abbc47f286.pdf

以下是精彩内容收拾:


双十一订单全链路


从图中能够看出,整个双十一订单处理过程中首要涉及到三个体系:渠道(天猫、淘宝)、ERP/OMS(用来处理订单)、WMS(库房内的打包、发货)。其间包含了八个状况:拉单能够渠道供给的订单API来完结,ERP/OMS进行转单、审单、打单,WMS供给拣货、打包、发货,最终要把状况进行回写。订单回写完结之后,订单状况就会在淘宝订单的物流概况中显示出来。

针对双十一订单的整个链路,接下来首要给咱们引荐渠道供给的几个产品,让订单同步和处理愈加高效:订单同步经过数据推送(订单同步服务)、面单打印经过菜鸟电子面单、库房对接经过奇门数据总线,订单状况回写经过批量API。


订单同步与处理要害接口

订单同步API:

  • taobao.trades.sold.get(获取三个月内已卖出的订单)

  • taobao.trades.sold.increment.get(增量获取产生改变的订单)

  • taobao.trade.fullinfo.get(获取单笔订单详细信息)

打单面单API:

  • taobao.wlb.waybill.i.get(获取电子面单号)

状况回写API:

  • taobao.tmc.message.produce(订单状况回流)

  • taobao.logistics.offline.send(物流发货回写)


传统的订单同步办法

传统的订单同步办法首要分为三个流程。


榜首个流程是初始化流程,新的用户进来之后需求给其授权,然后后台需求异步发动一个新的线程把订单同步回来,一般最多同步三个月内已卖出的订单,此外还需求调用订单概况接口获取单笔订单概况。

第二个是增量同步流程。订单在不断的产生和改变,需求在后台守时同步增量的订单,所以应该在后台守时起一些异步的线程去同步这个运用里一切已授权用户的增量订单,然后经过订单概况接口获取订单概况,而且把最终的同步时刻点存储起来以便下次运用。

第三个是实时同步流程,首要运用于自动发货等实时处理的场景。淘宝敞开渠道供给了自动告诉的音讯服务才能。接收到订单改变的实时音讯之后,经过订单概况接口,就能够拿到订单概况更新本地数据。

经过这三个流程,咱们能够组合出许多计划。榜首种是“全量+增量”的计划,能够完结订单的初始化、增量同步,适用于大部分的事务场景;第二种是“全量+实时”的计划,存在的问题是部分订单的改变或许没有发音讯,适用于对数据精确性要求不是十分高的实时订单处理场景;第三种是“全量+实时+对单”的计划,能够确保整个订单同步的实时牢靠,适用于对数据精确性和实时性要求极高的场景。


高效运用订单同步API

taobao.trades.sold.get(获取三个月内已卖出的订单):运用use_has_next=true的办法分页,每次分页能够削减一次db count,进步API分页查询的功率;关于订单量大的卖家,需求切分时刻段,比方按天获取,双十一峰值时段乃至切分到按分钟获取;需求调用taobao.trade.fullinfo.get获取概况的状况下,批量接口设置fields=tid能够直接走DB索引,取得更高的功率。

taobao.trades.sold.increment.get(增量获取改变的订单):不能早年往后翻页,否则已翻页的订单产生改变,会导致后续页数的订单前移,前移订单将会遗失,正确的做法是从后往前翻页;初次恳求运用use_has_next=false获取改变总数,后续恳求经过use_has_next=true分页,每次分页能够削减一次db count;需求调用taobao.trade.fullinfo.get获取概况的状况下,批量接口设置fields=tid能够直接走DB索引,取得更高的功率。


常见的漏单原因

  • 批量订单查询type入参设置不完整

  • 增量同步订单没有从后往前翻页

  • 增量同步订单时刻片没有堆叠

  • 增量同步订单没有往前追溯必定的时刻(比方5~30分钟)

  • 程序简略粗犷,时刻片不切分,导致API调用频频超时

  • 订单的部分特色改变并不会发自动告诉音讯

  • 极少数状况下,有一些订单产生了改变,但修正时刻没变


更深层次的漏单原因


图中是淘宝天猫买卖的机房散布,其分为中心机房和单元机房。中心机房放着买家库的主库,单元机房也会相同放买家库的主库。顾客下单后,订单会直接落入买家库里边,中心机房和单元机房会经过DRC进行双向数据同步,一同在买家库的基础上同步出了卖家库用来查询已卖出的宝物,在卖家库基础上同步出了卖家库的备库,而这个备库才是真实对外供给买卖批量API的库。买卖批量API直接查询的是卖家库的备库,而买卖概况API是相关的买家库。买家库是一个实时的库,而卖家库是由买家库同步过来的。卖家库主库与备库之间在高压状况下(双十一)会呈现同步推迟导致批量查询订单遗失。这种状况下的漏单是十分难以处理的,比较粗犷的做法是每天清晨全量对昨日的订单再进行一次同步,但价值很高。

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


数据推送——订单同步服务

订单同步服务产生的布景是漏单处理本钱高、API轮询实时性不高、大卖家数据难同步,该服务的定位是面向公网的数据同步服务,做到把阿里内部的数据库经过订单同步服务数据推送能够实时牢靠的推送到ISV数据库。现在现已做到了一致性(数据完全一致,不漏单)、高实时(秒级完结数据同步)、通用化(千人千面,自助接入和注册)、可弹性(可横向扩展、支撑亿级数据同步)。


数据推送架构


如上图所示,整个数据推送的架构分为两部分:布置在阿里内网的数据推送的服务端、淘宝敞开渠道的API服务和音讯服务;在聚石塔内布置的数据推送的客户端、ISV运用服务器以及ISV的RDS。


数据推送的规划要害包含:

牢靠音讯+对单补单:经过牢靠的音讯服务确保订单实时推送到RDS里边;经过增量API、大数据、ODPS进行对单补单,确保订单状况与淘宝完全一致;

分组阻隔+双机房容灾:数据推送客户端选用了分组阻隔的办法,为每一个分组至少分配两台以上的机器,而且分到不同的机房,即便其间一个机房宕机了,也不会影响数据的正常推送,而且阻隔各运用之间的影响;

中心表+大字段:数据库上选用中心表和大字段的规划,适配各种ISV的个性化字段推送需求;

批量刺进+更新优先:订单RDS选用批量刺进,进步写入功率,订单产生改变后,选用更新优先,防止每次更新都要先查询一次DB,削减对DB的查询次数;

兼容API恳求成果:存储到RDS里边的数据是兼容API恳求的JSON回来格局,能够运用TOP供给的SDK直接解说成买卖目标;

独享RDS+就近拜访:RDS是各运用独享的,拜访频率和功能由ISV自己操控,不会像API那样受别人的影响。整个RDS和数据推送客户端是放在一同的,数据推送能够就近拜访,同步功率更高。


数据推送中心表规划


中心表分为要害字段、体系字段和大字段。要害字段是订单里边比较重要的字段,比方买卖ID、买卖状况、买卖类型等。体系字段是用于整个数据推送在进行订单的增、删、改、查以及对单时所用到的字段。大字段是订单概况API回来的整个JSON字符串,可任意定制需求回来的字段。 


数据推送最佳实践

  • 先看官方的运用说明(查找“订单同步服务运用”)

  • 按需设置需求推送的字段及历史数据

  • 按需设置体系库保存时长(最短能够设置为2天)

  • 引荐运用“jdp_modified字段+倒排序+逆向翻页”获取增量订单

  • 不要对sys_info库的表进行count,查询尽量走索引

  • 多RDS运用,尽或许确保用户均匀散布

  • RDS引荐规范,“每1万用户+保存2天”挑选IOPS为600~1200的RDS


官方库房对接规范——奇门



奇门的优势

  • ERP与WMS互通规范,现在已界说36个规范API接口,掩盖常用场景

  • 掩盖面广,干流的ERP与WMS都已接入

  • 高效对接,白皮书、API在线文档、奇门SDK、挡板自测

  • 安稳,久经考验的高牢靠、高功能网关,支撑商家级流量操控

  • 安全,API恳求不行篡改,不行重放,双向授权认证

  • 追溯,一切API恳求记载耐久化存储,体系胶葛有据可查


奇门最佳实践

  • 运用挡板测验下降联调本钱

  • 运用奇门SDK下降编码本钱

  • 不同体系之间的通讯简单呈现超时问题,中心操作最好做幂等机制

  • 规范没有供给的字段,可经过extendProps个性化设置

  • 网络推迟低的状况下,走批量接口进步功率


高效订单回写办法——批量API

除了聚石塔内的API调用以外,有些商家会在移动端或许作业网络中调用API,比方在千牛插件里边调用API,此刻的功率一般很差,由于在弱网环境下,每次API恳求的TCP的三次握手树立衔接时长更高,每次API调用整体时长比在聚石塔里边调用要高许多。曾经敞开渠道也供给了两种批量API调用办法来处理这个问题:一个是TQL,但TQL调用办法,不易了解,串行调用,安全隐患高;别的一个是ATS,但ATS供给本钱高,运用杂乱,实时性差。批量API能够做到高功能、低推迟、通用化、简单运用。


批量API架构


如上图所示,最上层是SDK,其作用是把各种API的恳求进行兼并,路由到相应的服务去进行调用。第二层是异地多活,SDK能够依据就近准则调用到相应的机房。第三层是TOP网关渠道,一个恳求进来之后会做API的校验、安全、流控等规矩的校验等,校验经往后才会把API进行拆分,一个批量API恳求拆分红N个API恳求,然后把恳求提交到后台相应的供给服务才能的机器上,等候后台服务处理完之后经过NIO的网络事情回来唤醒作业线程,作业线程会把后端回来的成果进行数据的转化包含安全过滤、日志打点等,直到一切恳求处理完之后会进行API的搜集、排序、兼并、导出,最终把恳求唤醒回来给客户端的SDK。整个服务端在处理批量API的过程中,选用了全异步化的处理,不论一次建议多少次API恳求,都不会影响服务端的安稳性和功率,这是批量API差异于TQL和ATS最底子的当地。


批量API协议


单个API的协议经过签名、头部参数的设置、事务参数的组装完结一个API的调用。批量API的协议和单个API协议的差异比较小,仅有的差异是body里边的参数,引进了一个公共参数,能够放到公共字段中防止重复传送,削减网络开支。不同API的参数放到子参数列表中,而且经过-s-的分隔符分隔。

批量API的几个特色:Payload以form的方法去承载每个API,默许以\r\n-S-\r\n进行切割(也支撑自界说分隔符);榜首行#PUBLIC#开端,可提取公共参数和API称号;参数优先级:子API参数 ===掩盖=== #PUBLIC#参数 ===掩盖=== URL参数;签名办法,根据rest签名:byte2hex (hmac(key1value1key2value2...payloadsecret))。 


批量API与一般API比较


单个API的调用办法比较了解,比方调用订单概况API,首要创立淘宝的客户端,然后新建调用订单概况的request,设置要查询的订单字段,每个恳求履行一次request。批量API引进TaobaoBatchRequest的目标,不会每次恳求都增加相同的字段,只需求去新建不同的request,追加到batch request中,最终只建议一次API调用即可。批量API调用与串行API调用比较发现,批量API调用和单次API调用时刻挨近,远比串行API调用功率高。



2016杭州 • 云栖大会——开发者技能峰会

架构

 

2016年10月15日
 

杭州·云栖小镇
峰会议程




13:30-13:40 致辞
杨名 阿里云事务运营事业部总经理

13:40-14:20 架构实战或架构师生长之路
 旭卿 阿里云资深专家

14:20-15:00 Docker大规模运用带来的架构规划新应战
吴峥涛 蚂蚁金服高档技能专家

15:00-15:40 微博混合云,极点流量下的峰值应对与架构应战
 王关胜 新浪微博资深运维架构师

15:40-16:20 千万级用户直播App服务端架构规划和考虑
雷涛 一直播CTO

16:20-17:00 根据机器学习的阿里智能助理在电商范畴的架构构建与实践
海青 阿里巴巴高档技能专家





本文来自网络,不代表快递资讯网立场。转载请注明出处: http://www.llaiot.com/logistics-news/2758.html
上一篇
下一篇

为您推荐

返回顶部