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

另外,一些广告的价格服务,我们会优先降级,如果出问题的话会限制.另外,有一部分刷引擎刷价格服务的数据,正常情况下是保证它正常使用,但是一旦出现问题,我们会直接把它降级,这样就保护了真实用户的最好体验,而不是直接清除程序的应用.

容灾降级

每次双11活动,我们会做很多的容灾和降级,有多中心交易、机房容灾、业务容灾等各种纬度的容灾.大概统计了一下做过的一些容灾方案.

首先是网络容灾.前面说到SB中间件、域名解析,我们运维自己会做了核心交换机两层专线.这是我们运维部做的一些网络架构图,两边相互容灾的一个结构.有LVS、HA、域名及解析,只是单服务挂了,通过交换机,我们可以从一个机房切换到另一个机房,因为会做一些域名的解析和切换.

应用系统相互调用容灾和降级：结算的容灾和降级.应用系统大部分能够降,比如库存状态.如果像优惠券这些不重要的服务,备注信息,可直接降级服务,不用去访问它,直接提交就行.在提交订单时候,首先我们会保证必要服务,这些服务都会有很多的保护措施.每个应用里面,应用级别、服务级别的容灾,比如地址服务、库存状态容灾可以直接先降级.到提交的时候,我们直接对库存做限制.

应用内部的容灾.库存就是结算前面的系统应用的服务,再到细一层的我们的库存服务,这是每一个服务的容灾降级.从库存状态这边的话,从网络设备内层,有网络容灾降级.应用内部有对于预算服务的降级,预算服务会有预算库存,原来是写MySQL数据库.

正常情况下,预算库存是写MASIC预算库,当出现问题的时候,我们会异步堆列到本地机器,装一个程序去承载这个异步MySQL数据的落地,然后再通过Work把它写到MySQL服务里面.正常情况下,是双写MySQL、redis,当MySQL承载不住的时候,我们会把MySQL异步写到里面.

这里面都会有开关系统去控制.当提交订单产生变更的时候,才会把库存状态从这边推到这个库存状态这边,因为库存状态的调用量跟价格一样很大.今年我们看到的最大调用量是一分钟2600万.

这样不可能让它直接回原到MySQL,跟直接库存的现实存储里面.通过预算系统把这个状态从左边算好,直接在推送过到真正的存储,这样就把这个存储剥离出来,这也算一种异步异构,这样我们会提升它的容量.

这是原来的结构,就是redis直接同步,然后直接访问.现在把它改成是,直接让左边的预算服务去推送到状态服务里面.

监控

最后主要就是监控系统,我们运维提供了网络监控、机器监控.

（编辑：济源站长网）

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