?

京东到家订单查询服务演进

作者:媒体转发 时间:2019-09-01 21:12

字号

京东到家订单中心系统业务中,无论是外部商家的订单生产,或是内部上下游系统的依赖,订单查询的调用量都非常大,造成了订单数据读多写少的情况。京东到家的订单数据存储在Mysql中,但显然只通过DB来支撑大量的查询是不可取的,同时对于一些复杂的查询,Mysql支持得不够友好,所以订单中心系统使用了Elasticsearch来承载订单查询的主要压力。

京东到家订单查询服务演进

Elasticsearch 做为一款功能强大的分布式搜索引擎,支持近实时的存储、搜索数据,在京东到家订单系统中发挥着巨大作用,目前订单中心ES集群存储数据量达到10亿个文档,日均查询量达到5亿。随着京东到家近几年业务的快速发展,订单中心ES架设方案也不断演进,发展至今ES集群架设是一套实时互备方案,很好的保障了ES集群读写的稳定性,下面就给大家介绍一下这个历程以及遇到的一些坑。

ES集群架设演进历程:

1. 初始阶段:

订单中心ES初始阶段好如一张白纸,架设方案基本没有,很多配置都是保持集群默认配置。整个集群部署在集团的弹性云上,ES集群的节点以及机器部署都比较混乱。同时按照集群维度来看,一个ES集群会有单点问题,显然对于订单中心业务来说也是不被允许的。

2. 集群隔离阶段:

和很多业务一样,ES集群采用的混布的方式。但由于订单中心ES存储的是线上订单数据,偶尔会发生混布集群抢占系统大量资源,导致整个订单中心ES服务异常的情况。

显然任何影响到订单查询稳定性都是无法容忍的,所以针对于这个情况,先是对订单中心ES所在的弹性云,迁出那些系统资源抢占很高的集群节点,ES集群状况稍有好转。但随着集群数据不断增加,弹性云配置已经不太能满足ES集群,且为了完全的物理隔离,最终干脆将订单中心ES集群部署到高配置的物理机上,ES集群性能又得到提升。

3. 节点副本调优阶段:

ES的性能跟硬件资源有很大关系,当ES集群单独部署到物理机器上时,集群内部的节点并不是独占整台物理机资源,在集群运行的时候同一物理机上的节点仍会出现资源抢占的问题。所以在这种情况下,为了让ES单个节点能够使用最大程度的机器资源,采用每个ES节点部署在单独一台物理机上方式。

但紧接着,问题又来了,如果单个节点出现瓶颈了呢?我们应该怎么再优化呢?ES查询的原理,当请求打到某号分片的时候,如果没有指定分片类型(preference参数)查询,请求会负载到对应分片号的各个节点上。而集群默认副本配置是一主一副,针对于此,我们想到了扩容副本的方式,由默认的一主一副变为一主二副,同时增加相应物理机。

京东到家订单查询服务演进

如上图,订单中心ES集群架设示意图。整个架设方式通过VIP来负载均衡外部请求,第一层gateway节点实质为ES中client node,相当于一个智能负载均衡器,充当着分发请求的角色。第二层为data node,负责存储数据以及执行数据的相关操作。整个集群有一套主分片,二套副分片(一主二副),从网关节点转发过来的请求,会在打到数据节点之前通过轮询的方式进行均衡。集群增加一套副本并扩容机器的方式,增加了集群吞吐量,从而提升了整个集群查询性能。下图为订单中心ES集群各阶段性能示意图,直观的展示了各阶段优化后ES集群性能的显着提升。

京东到家订单查询服务演进

当然分片数量和分片副本数量并不是越多越好,在此阶段中,对选择适当的分片数量做了近一步探索。分片数可以理解为Mysql中的分库分表,而当前订单中心ES查询主要分为两类:单ID查询以及分页查询。分片数越大,集群横向扩容规模也更大,根据分片路由的单ID查询吞吐量也能大大提升,但对于聚合的分页查询性能则将降低。分片数越小,集群横向扩容规模更小,单ID的查询性能也将下降,但对于分页查询,性能将会得到提升。所以如何均衡分片数量和现有查询业务,我们做了很多次调整压测,最终选择了集群性能较好的分片数。

4. 主从集群调整阶段:

到此,订单中心的ES集群已经初具规模,但由于订单中心业务时效性要求高,对于ES查询稳定性要求也高,如果集群中有节点发生异常,查询服务会受到影响,从而影响到整个订单生产流程。显而易见这种异常情况是致命,所以为了应对这种情况,我们初步设想是增加一个备用集群,当主集群发生异常时,可以实时的将查询流量降级到备用集群。

责任编辑:CQITer新闻报料:400-888-8888 ? 本站原创,未经授权不得转载
关键词 >> 京东到家,订单查询,数据存储
继续阅读
热新闻
推荐
关于我们联系我们免责声明隐私政策 友情链接