Elasticsearch|MySQL用得好好的，为什么要转ES? 来源：京东技术（jingdongjishu）

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