日均5亿查询量的京东到家订单中心，为什么舍MySQL用ES?

京东到家订单中心系统业务中，无论是外部商家的订单生产，或是内部上下游系统的依赖，订单查询的调用量都非常大，造成了订单数据读多写少的情况。

我们把订单数据存储在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查询稳定性要求也高，如果集群中有节点发生异常，查询服务会受到影响，从而影响到整个订单生产流程。很明显这种异常情况是致命的，所以为了应对这种情况，我们初步设想是增加一个备用集群，当主集群发生异常时，可以实时的将查询流量降级到备用集群。

那备用集群应该怎么来搭?主备之间数据如何同步?备用集群应该存储什么样的数据?

考虑到ES集群暂时没有很好的主备方案，同时为了更好地控制ES数据写入，我们采用业务双写的方式来搭设主备集群。每次业务操作需要写入ES数据时，同步写入主集群数据，然后异步写入备集群数据。同时由于大部分ES查询的流量都来源于近几天的订单，且订单中心数据库数据已有一套归档机制，将指定天数之前已经关闭的订单转移到历史订单库。

所以归档机制中增加删除备集群文档的逻辑，让新搭建的备集群存储的订单数据与订单中心线上数据库中的数据量保持一致。同时使用ZK在查询服务中做了流量控制开关，保证查询流量能够实时降级到备集群。在此，订单中心主从集群完成，ES查询服务稳定性大大提升。

5、现今：实时互备双集群阶段

期间由于主集群ES版本是较低的1.7，而现今ES稳定版本都已经迭代到6.x，新版本的ES不仅性能方面优化很大，更提供了一些新的好用的功能，所以我们对主集群进行了一次版本升级，直接从原来的1.7升级到6.x版本。

集群升级的过程繁琐而漫长，不但需要保证线上业务无任何影响，平滑无感知升级，同时由于ES集群暂不支持从1.7到6.x跨越多个版本的数据迁移，所以需要通过重建索引的方式来升级主集群，具体升级过程就不在此赘述了。

（编辑：济南站长网）

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