大促订单、PV双线破亿，解密京东商城交易系统的演进之路

购物车从2010年就开始Java改造,整体结构的划分主体有,促销引擎、商品、用户.系统结构在2012年已经成型.到13年,加入了购物车服务的存储.原来购物车存储的商品是在浏览器端的Cookie里的,用户更换一台设备,之前加入的商品就会丢失掉.为了解决这个需求,我们做了购物车服务端存储,只要登录,购物车存储就会从服务端拿取.然后通过购车服务端存储打通了手机端与PC端等的存储结构,让用户在A设备加入商品,在另外一个设备也能结算,提高用户体验.

异步异构

2013年之后,接入了很多其他业务,如跟腾讯合作,有微信渠道,我们会把存储分为几份,容量就会逐步地放大.这是异步的存储,手机端会部署一套服务,PC端会部署一套服务,微信端会部署一套服务.就会隔离开来,互不影响.

购物车就是这么做的.购物车整个数据异步写的时候都是全量写的.上一次操作可能异步没写成功,下一次操作就会传导都写成功了.不会写丢,但是可能会有一下延时,这些数据还是会同步过来.比如,从PC端加入商品之后没有立即同步到移动端,再勾选下购物车,购物车的存储又会发生变更,就会直接把全部数据同步到移动端.这样,我们的数据很少会出现丢失的情况.

异步写的数据是进行了很多的压缩的.第一层压缩从前端开始,整个前端是一个接口串,到后面购物车服务,先把它压缩为单个字母的接口串,后面又会压缩成字节码,使字节流真正存储到redis层里面.当存储压缩得很小的时候,性能也会提高.

缓存压缩只是为提升纵向性能做的改进.后面还会进行横向异步异构的改进,购物车把移动端存储剥离出去,移动端的存储在一组redis上,PC端的存储在另外一组上.PC端和移动端是异步去写,这样相互不影响,虽然它们的数据是同步的.这是针对多中心用户所做的一些改进.

外层的异步,是做一些不重要的服务的异步,就从购物车前端看到的地址服务、库存状态服务.库存状态服务在购物车只是一些展示,它不会影响主流层、用户下单.真正到用户提交的时候,库存数据才是最准确的.这样,我们会优先保证下单流程.

接下来讲讲接单的异步.提交订单,提交一次订单原来需要写10多张表.当订单量提高到一分钟10万的时候,系统就无法承受.我们就把整个提交订单转成XML,这样只写一张表,后面再去做异步.接单的第一步,先是把整个订单所有信息存储下来,然后再通过状态机异步写原来的10多张表数据.

关于订单中心的异步异构,订单中心原来都是从订单表直接调出的.随着体量增大,系统无法承载访问,我们异构出订单中心的存储,支付台帐存储等. 异构出来数据都具有业务针对性存储.数据体量会变小,这样对整体的优化提升提供很好的基础.

这样的存储隔离,对订单状态更新压力也会减小,对支付的台帐、对外部展示的性能也会提升.大家会疑问,这些数据可能会写丢.我们从第一项提交开始,直接异步写到订单中心存储,到后面订单状态机会补全.如果拆分不出来,后面就生产不了.也就是说,到不了订单中心,数据生产不了,一些异步没成功的数据就会在这个环节补全.

然后是商品的异步异构.2013年,商品团队面临的访问量,已经是几十亿.如何去应对这个情况呢?很多商品数据贯穿了整个交易,包括交易的分析、各个订单的系统都会调商品系统.我们会针对系统优化.

比如,针对促销系统调用,促销系统主要调用特殊属性,我们把这些属性存到促销系统的特有存储.库存系统也类推.调用的特殊属性的方法也不一样.譬如大家电的长宽高这些特有属性,不像前端商品页里只是基本属性.这样就把所有的属性异构处理,针对商品纬度、商品ID等所有数据会异构一份到库存、促销、单品页,后面进行改造的时候,又将数据分A包、B包、C包.

京东的业务很复杂,有自营,又有平台数据,A包可能是基础数据,B包可能是扩展数据,C包可能是更加偏的扩展数据.这样,促销系统可能调用的是B包的扩展属性,也有可能调用的是A包的基础属性.单品页访问A包、B包,调的集群是不一样的.这样存储的容量就可以提高两倍,系统的容灾承载力也会提高.

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!