Elasticsearch|MySQL用得好好的,为什么要转ES?


Elasticsearch|MySQL用得好好的,为什么要转ES?文章插图
来源:京东技术(jingdongjishu)
京东到家订单中心系统业务中 , 无论是外部商家的订单生产 , 或是内部上下游系统的依赖 , 订单查询的调用量都非常大 , 造成了订单数据读多写少的情况 。
我们把订单数据存储在MySQL中 , 但显然只通过DB来支撑大量的查询是不可取的 。 同时对于一些复杂的查询 , MySQL支持得不够友好 , 所以订单中心系统使用了Elasticsearch来承载订单查询的主要压力 。
Elasticsearch|MySQL用得好好的,为什么要转ES?文章插图
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参数)查询 , 请求会负载到对应分片号的各个节点上 。 而集群默认副本配置是一主一副 , 针对此情况 , 我们想到了扩容副本的方式 , 由默认的一主一副变为一主二副 , 同时增加相应物理机 。
Elasticsearch|MySQL用得好好的,为什么要转ES?文章插图
订单中心ES集群架设示意图
如图 , 整个架设方式通过VIP来负载均衡外部请求:
整个集群有一套主分片 , 二套副分片(一主二副) , 从网关节点转发过来的请求 , 会在打到数据节点之前通过轮询的方式进行均衡 。 集群增加一套副本并扩容机器的方式 , 增加了集群吞吐量 , 从而提升了整个集群查询性能 。
下图为订单中心ES集群各阶段性能示意图 , 直观地展示了各阶段优化后ES集群性能的显著提升:
Elasticsearch|MySQL用得好好的,为什么要转ES?文章插图
当然分片数量和分片副本数量并不是越多越好 , 在此阶段 , 我们对选择适当的分片数量做了进一步探索 。 分片数可以理解为MySQL中的分库分表 , 而当前订单中心ES查询主要分为两类:单ID查询以及分页查询 。
分片数越大 , 集群横向扩容规模也更大 , 根据分片路由的单ID查询吞吐量也能大大提升 , 但聚合的分页查询性能则将降低;分片数越小 , 集群横向扩容规模也更小 , 单ID的查询性能也会下降 , 但分页查询的性能将会提升 。
所以如何均衡分片数量和现有查询业务 , 我们做了很多次调整压测 , 最终选择了集群性能较好的分片数 。
4、主从集群调整阶段
到此 , 订单中心的ES集群已经初具规模 , 但由于订单中心业务时效性要求高 , 对ES查询稳定性要求也高 , 如果集群中有节点发生异常 , 查询服务会受到影响 , 从而影响到整个订单生产流程 。 很明显这种异常情况是致命的 , 所以为了应对这种情况 , 我们初步设想是增加一个备用集群 , 当主集群发生异常时 , 可以实时的将查询流量降级到备用集群 。