泉源：京东技术（ID: jingdongjishu）京东抵家订单中心系统业务中，无论是外部商家的订单生产，或是内部上下游系统的依赖，订单查询的挪用量都很是大，造成了订单数据读多写少的情况。我们把订单数据存储在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来负载平衡外部请求：整个集群有一套主分片，二套副分片（一主二副），从网枢纽点转发过来的请求，会在打到数据节点之前通过轮询的方式举行平衡。集群增加一套副本并扩容机械的方式，增加了集群吞吐量，从而提升了整个集群查询性能。下图为订单中心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跨越多个版本的数据迁移，所以需要通过重建索引的方式来升级主集群，详细升级历程就不在此赘述了。主集群升级的时候必不行免地会发生不行用的情况，但对于订单中心ES查询服务，这种情况是不允许的。

所以在升级的阶段中，备。

本文来源：博鱼体育-www.123psycho.com