目前的订单系统ES采用默认的刷新配置因此对于具有较高实时订单数据的服务，直接到数据库查询以保证数据的准确性同时，备用集群为主集群的功能增加了一个键兩个集群的状态同样重要，但每个集群都可以降级到另一个集群对双写入策略也进行了如下优化：假设存在AB集群，则通常的同步写入主(A集群)异步写入(B集群)当A集群中出现异常时，同步写入B集群(Main)和异步写入A集群(备用)熟悉ES写入机制的学生可能知道，新文档被收集到索引Bffer中並写入文件系统缓存，并且可以像文件系统缓存中的其他文件一样进行索引

考虑到订单系统中ES服务的业务特殊性，订单数据的实时性很高而BINLOG的监控方式显然等同于异步同步，可能会产生很大的延迟备选方案1基本上类似于方案2，但已经采用了一种新的系统并增加了维護费用。因此订单中心ES采用直接通过ESAPI编写订单数据的方式，简单灵活能够满足订单中心数据与专家系统同步的需要。架构的快速迭代源于业务的快速发展近年来，随着家庭业务的快速发展订单中心的体系结构也在不断优化和升级。而架构方案并不是最好的只是最匼适的。

我相信未来几年，订单中心的体系结构将是另一种面貌但其吞吐量更大，性能更好稳定性更强，这将是订单中心系统的永恒追求升级主集群时不可避免地会出现不可用性，但订单中心ES查询服务不允许这样做因此，在升级阶段备用集群暂时充当支持所有茬线ES查询的主群集，以确保升级过程不会影响正常的在线服务同时，对于在线业务我们对这两个集群做出了新的规划定义，并对在线查询流量进行了重新划分方案1：听Binlog，分析MySQL的Binlog将数据同步到ES集群中。场景2：通过ESAPI将数据直接写入ES集群-=YTET-Edensubtitlegroup=-Translation:当然，切片的数量和拷贝的数量並不好在现阶段，我们进一步探讨了适当的切片数目的选择

片数可以理解为MySQL中的库表，而当前的订单中心ES查询主要分为两类：单ID查询囷分页查询备用集群最近几天将热点数据存储在线路上，数据规模远小于主集群主集群文档中约10%的集群数据量较小，在相同的集群部署规模下备用集群的性能优于主集群。但是默认情况下，从索引Bffer到文件系统缓存(即刷新操作)的文档会以每秒切片的形式自动刷新因此我们说ES是一个近乎实时的搜索，而不是实时搜索：文档中的更改在搜索中不是立即可见而是在一秒内变得可见。DocVales是一种类似于FieldData的列数據存储结构但它的存储位置位于Lcene文件中，也就是说它不占用JVM堆。使用ES版本的迭代DocVales比FieldData更稳定，DocVales是x的默认设置片数越多，集群的水平嫆量扩展规模越大单ID查询吞吐量的分段路由也可以大大提高，但聚合寻呼查询的性能会降低；片数越少集群的水平扩展规模越小，单個ID的查询性能也会降低但寻呼查询的性能会得到改善。

到目前为止订单中心的ES集群已经开始形成，但由于订单中心业务的高时效性要求ES查询的稳定性也较高。如果集群中存在异常节点查询服务就会受到影响，从而影响到整个订单生产过程显然，此异常是致命的洇此为了处理这种情况，我们最初设想添加备用群集当主集群中出现异常时，查询流量可以实时降为备用群集整个集群有一组主片和兩组子片(一个主片和两个子片)。

在到达数据节点之前将通过轮询来平衡从网关节点转发的请求。集群添加了一组副本并扩展了机器从洏提高了集群的吞吐量，从而提高了整个集群的查询性能那么，如何构建备用集群呢如何同步主机和待机之间的数据？备用集群应该存储什么样的数据和许多企业一样，ES集群采用混合分布方式然而，由于订单中心ES存储在线订单数据偶尔会出现混合分布簇抢占系统資源，导致整个订单中心ES服务异常

如果没有足够的空间，删除FieldData和加载一个新的FieldData缓存的过程在不使用(LR)算法的情况下加载时间最长，消耗叻系统资源花费了大量的时间。结果这个查询的响应时间猛增，甚至影响整个集群的性能为了解决这一问题，解决方案是采用DocVales但昰问题再次出现了，如果单个节点存在瓶颈怎么办我们应该如何优化它？在线查询偶尔超时通过调试查询语句，定位与排序有关

排序在esx版本中使用FieldData结构，FieldData占用JVM堆内存JVM内存有限，并为FieldData缓存设置阈值集群升级过程繁琐而漫长，不仅需要保证在线业务的无影响、平滑和非感知的升级而且由于ES集群不支持多个版本的数据从7到x的迁移，因此有必要通过索引的重构来升级主集群而没有描述具体的升级过程。ES查询的原理是当请求调用某个数字切片时，如果没有指定的切片类型(首选参数)查询则请求将加载到相应切片编号的每个节点上。鉴於集群的默认副本配置是一个主服务器和一个副本对我们考虑如何将副本从默认的一个主服务器扩展到一个主服务器和两个对，同时添加相应的物理机器

显然，任何影响订单查询稳定性的情况都是无法容忍的因此对于这种情况，首先对于订单中心ES弹性云，从系统资源抢占的集群节点中移出ES集群情况略有改善。然而随着集群数据量的不断增加，灵活的云配置已经不能满足ES集群的需求为了完成物悝隔离，最终将有序中心ES集群部署到高配置的物理机器上提高了ES集群的性能。ES集群的分页查询支持从参数和大小参数在查询时，每个爿段必须从+size构造长度的优先级队列然后将其返回到网关节点，然后对网关节点进行排序以找到正确的大小文档。

因此只有当业务操莋更新ES时，如果发生错误或异常将补救任务插入数据库，一些工作任务将实时扫描数据并根据数据库订单数据再次更新ES数据。通过这種补偿机制可以保证ES数据与数据库订单数据的最终一致性。因此如何平衡片数和现有查询业务，进行了大量的调整压力测量最终选擇了具有良好聚类性能的片数。由此可见当FROM足够大时，即使OOM没有发生也会影响CP和带宽，从而影响整个集群的性能因此，您应该避免罙度分页查询并尽量不使用它们。

因为ES订单数据的同步是在业务中写入的因此，如果在创建或更新文档时发生异常则重试一定会影響业务正常运行的响应时间。专家系统的性能与硬件资源有很大关系当ES集群单独部署到物理机器上时，集群节点不会独占整个物理机器資源而同一物理机器上的节点在运行时仍然存在资源抢占问题。因此在这种情况下，为了使单个ES节点能够使用最大数量的机器资源烸个ES节点被部署在一个单独的物理机器上。因此将删除备用群集文档的逻辑添加到归档机制中，从而使新构建的备用集群中存储的订单數据与订单中心线上数据库中的数据量保持一致同时，利用ZK实现查询服务中的流量控制切换保证查询流量能够实时降为待机机群。

在此完成了订单中心主从式集群，极大地提高了ES查询服务的稳定性近年来，随着京东业务的快速发展订单中心ES***方案也在不断发展。到目前为止ES集群设置是一套实时的互备方案，保证了ES集群读写的稳定性下面，我们将介绍这个过程和在这个过程中遇到的一些漏洞

本文给出了订单中心ES集群各个阶段的性能，并直观地显示了各阶段优化后ES集群性能的显著提高：在此期间由于主集群的ES版本较低，而現在ES的稳定版本已被迭代到x因此新版本的ES不仅在性能上得到了极大的优化，而且还提供了一些新的易于使用的特性因此我们对主集群進行了版本升级，直接从原来的7版本升级到x版本假设在一个包含六个主要片段的索引中，FROM为10000大小为10，每个切片必须生成10010个结果在网關节点中合并60060个结果，最后找到满足要求的10个文档当MySQL数据被同步到ES中时，可以将总结分为两种情况：订单中心ES的初始阶段就像一张白纸***方案基本上是不可用的，很多配置都是为了维护集群的默认配置整个集群被部署在组的灵活云上，ES集群的节点和机器部署都是混亂的同时，从集群维度上看ES集群存在一个单一的问题点，这对于订单中心业务显然是不允许的在京东家庭订单中心系统的业务中，無论是外部商家的订单生产还是上下游系统的依赖，订单查询量都很大导致订单数据读写较少。我们将订单数据存储在MySQL中但显然只通过DB支持大量查询是不可取的。

同时对于一些复杂的查询，MySQL不够友好所以订单中心系统采用弹性搜索来承载订单查询的主要压力。例洳整个***模式通过VIP加载外部请求：ElasticSearch作为一种功能强大的分布式搜索引擎，支持几乎实时的存储和搜索数据在京东家庭点播系统中发揮着重要作用。目前按订单中心存储在ES集群中的数据量达到10亿个文档，平均每天的查询量达到5亿个张先生，京东研发工程师主要负責订单中心、商户中心、计费等系统。