大促订单、PV双线破亿，解密京东商城交易系统的演进之路
|
商品原来是一个单表,后来慢慢发展成为了一个全量的商品系统,包括前端、后端整个一套的流程.异步异构完了之后,系统可进行各方面的优化,这样系统的容量也会慢慢接近预期值.然后找到系统容量的最大值,如果超过这个值,整个系统就会宕机.那么,我们会做分流和限流,来保证系统的可用性.否则,这种大流量系统一旦倒下去,需要很长的时间才能恢复正常,会带来很大的损失. 分流限流
从Nginx,到Web层、业务逻辑层、数据逻辑层,就会分流限流,真正落到实际上的流量是很小的,这样就会起到保护作用,不会让后端的存储出现崩溃.从前面开始,可能访问价格或者购物车的时间是10毫秒,保证20台的机器一分钟的流量是一百万、两百万. 如果是40台机器的话,承载能力会很强,会透过Java的服务,压倒存储,这样会引发更大的问题,庞大存储一旦出现问题很难一下恢复.如果从前面开始一层一层往下限,就可以起到保护底层的作用.中间层出问题比较容易处理,如Web层,限流会消耗很多CPU,会一步步加入更多机器,这样就能够解决这个问题. 我们需要降级分流限流. 下面结合秒杀系统来讲讲如何限流分流.2014年才产生秒杀系统.当时,在同一时刻可能有1500万人预约抢一件商品,抢到系统不能访问.后端服务都没有出现这些问题,有的服务费不能正常展现.后来就专为抢购设计了一个秒杀系统.正常情况下,有大批量用户需要在同一时间访问系统,那么就从系统结构上分出去这些流量.秒杀系统尽量不影响主流层的入口,这样就分离出来一部分数据. 接下来讲讲促销和价格.主力调用价格的服务主要在促销引擎,限流主要是通过购物车服务,购物车到促销引擎又会限流,促销引擎里面会有令牌.比如,有5000个库存,发50万个令牌到前端去,肯定这5000个库存会被抢完,不可能再把其他服务的量打到后面,这样会保护促销引擎,这是一种总令牌模式的保护.后面的分流性能,会分集群式、重要程度去做. （编辑：济源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
