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

商品原来是一个单表,后来慢慢发展成为了一个全量的商品系统,包括前端、后端整个一套的流程.异步异构完了之后,系统可进行各方面的优化,这样系统的容量也会慢慢接近预期值.然后找到系统容量的最大值,如果超过这个值,整个系统就会宕机.那么,我们会做分流和限流,来保证系统的可用性.否则,这种大流量系统一旦倒下去,需要很长的时间才能恢复正常,会带来很大的损失.

分流限流

• Nginx层： 通过用户IP、Pin,等一下随机的key进行防刷.
• Web 层： 第一层,Java应用实列中单个实列每分钟,每秒只能访问多少次；第二层,业务规则防刷,每秒单用户只能提交多少次,促销规则令牌防刷.

从Nginx,到Web层、业务逻辑层、数据逻辑层,就会分流限流,真正落到实际上的流量是很小的,这样就会起到保护作用,不会让后端的存储出现崩溃.从前面开始,可能访问价格或者购物车的时间是10毫秒,保证20台的机器一分钟的流量是一百万、两百万.

如果是40台机器的话,承载能力会很强,会透过Java的服务,压倒存储,这样会引发更大的问题,庞大存储一旦出现问题很难一下恢复.如果从前面开始一层一层往下限,就可以起到保护底层的作用.中间层出问题比较容易处理,如Web层,限流会消耗很多CPU,会一步步加入更多机器,这样就能够解决这个问题.

我们需要降级分流限流.

下面结合秒杀系统来讲讲如何限流分流.2014年才产生秒杀系统.当时,在同一时刻可能有1500万人预约抢一件商品,抢到系统不能访问.后端服务都没有出现这些问题,有的服务费不能正常展现.后来就专为抢购设计了一个秒杀系统.正常情况下,有大批量用户需要在同一时间访问系统,那么就从系统结构上分出去这些流量.秒杀系统尽量不影响主流层的入口,这样就分离出来一部分数据.

接下来讲讲促销和价格.主力调用价格的服务主要在促销引擎,限流主要是通过购物车服务,购物车到促销引擎又会限流,促销引擎里面会有令牌.比如,有5000个库存,发50万个令牌到前端去,肯定这5000个库存会被抢完,不可能再把其他服务的量打到后面,这样会保护促销引擎,这是一种总令牌模式的保护.后面的分流性能,会分集群式、重要程度去做.

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

容灾降级

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

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

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

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

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

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

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

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

监控

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

（编辑：ASP站长网）