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不仅在性能方面得到了极大的优化，而且还提供了新的易用性功能，因此将主群集一次性备份
由于群集升级过程繁琐漫长，对在线业务没有任何影响，不仅需要保证平稳、无意识的升级，而且ES群集暂时不支持跨1.7到6.x多个版本的数据迁移具体的升级过程在此不再赘述。
当主群集升级时，不可避免地会出现不可用的情况，但订单中心ES查询服务不允许出现这种情况。 因此，在升级阶段，备用群集将临时充当主群集，支持所有在线ES查询，以确保升级过程不影响正常的在线服务。 另外，对于在线业务，我们对两个集群进行了重新规划定义，并将负责的在线查询流量也进行了重新分类。
群集中存储了这几天在线热点的数据。 数据的规模远远小于主群集，约为主群集文档数量的十分之一
一。集群数据量小，在相同的集群部署规模下，备集群的性能要优于主集群。然而在线上真实场景中，线上大部分查询流量也来源于热点数据，所以用备集群来承载这些热点数据的查询，而备集群也慢慢演变成一个热数据集群。之前的主集群存储的是全量数据，用该集群来支撑剩余较小部分的查询流量，这部分查询主要是需要搜索全量订单的特殊场景查询以及订单中心系统内部查询等，而主集群也慢慢演变成一个冷数据集群。
同时备集群增加一键降级到主集群的功能，两个集群地位同等重要，但都可以各自降级到另一个集群。双写策略也优化为：假设有AB集群，正常同步方式写主（A集群）异步方式写备（B集群）。A集群发生异常时，同步写B集群（主），异步写A集群（备）。
ES 订单数据的同步方案MySQL数据同步到ES中，大致总结可以分为两种方案：
方案1：监听MySQL的Binlog，分析Binlog将数据同步到ES集群中。方案2：直接通过ES API将数据写入到ES集群中。考虑到订单系统ES服务的业务特殊性，对于订单数据的实时性较高，显然监听Binlog的方式相当于异步同步，有可能会产生较大的延时性。且方案1实质上跟方案2类似，但又引入了新的系统，维护成本也增高。所以订单中心ES采用了直接通过ES API写入订单数据的方式，该方式简洁灵活，能够很好的满足订单中心数据同步到ES的需求。
由于ES订单数据的同步采用的是在业务中写入的方式，当新建或更新文档发生异常时，如果重试势必会影响业务正常操作的响应时间。
所以每次业务操作只更新一次ES，如果发生错误或者异常，在数据库中插入一条补救任务，有Worker任务会实时地扫这些数据，以数据库订单数据为基准来再次更新ES数据。通过此种补偿机制，来保证ES数据与数据库订单数据的最终一致性。
遇到的一些坑1、实时性要求高的查询走DB
推荐阅读：ES 几十亿数据检索 3 秒返回。
对于ES写入机制的有了解的同学可能会知道，新增的文档会被收集到Indexing Buffer，然后写入到文件系统缓存中，到了文件系统缓存中就可以像其他的文件一样被索引到。
然而默认情况文档从Indexing Buffer到文件系统缓存（即Refresh操作）是每秒分片自动刷新，所以这就是我们说ES是近实时搜索而非实时的原因：文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。
当前订单系统ES采用的是默认Refresh配置，故对于那些订单数据实时性比较高的业务，直接走数据库查询，保证数据的准确性。
2、避免深分页查询
ES集群的分页查询支持from和size参数，查询的时候，每个分片必须构造一个长度为from+size的优先队列，然后回传到网关节点，网关节点再对这些优先队列进行排序找到正确的size个文档。
假设在一个有6个主分片的索引中，from为10000，size为10，每个分片必须产生10010个结果，在网关节点中汇聚合并60060个结果，最终找到符合要求的10个文档。
由此可见，当from足够大的时候，就算不发生OOM，也会影响到CPU和带宽等，从而影响到整个集群的性能。所以应该避免深分页查询，尽量不去使用。
3、FieldData与Doc Values
FieldData：
线上查询出现偶尔超时的情况，通过调试查询语句，定位到是跟排序有关系。排序在es1.x版本使用的是FieldData结构，FieldData占用的是JVM Heap内存，JVM内存是有限，对于FieldData Cache会设定一个阈值。
如果空间不足时，使用最久未使用（LRU）算法移除FieldData，同时加载新的FieldData Cache，加载的过程需要消耗系统资源，且耗时很大。所以导致这个查询的响应时间暴涨，甚至影响整个集群的性能。针对这种问题，解决方式是采用Doc Values。
Doc Values：
Doc Values是一种列式的数据存储结构，跟FieldData很类似，但其存储位置是在Lucene文件中，即不会占用JVM Heap。随着ES版本的迭代，Doc Values比FieldData更加稳定，Doc Values在2.x起为默认设置。
最后总结搞定算法，面试字节再不怕，有需要文章中分享的这些二叉树、链表、字符串、栈和队列等等各大面试高频知识点及解析，以及算法刷题LeetCode中文版的小伙伴们可以点赞后点击这里即可免费获取！
最后再分享一份终极手撕架构的大礼包(学习笔记)：分布式+微服务+开源框架+性能优化
q.com/doc/DSmxTbFJ1cmN1R2dB)**
最后再分享一份终极手撕架构的大礼包(学习笔记)：分布式+微服务+开源框架+性能优化
[外链图片转存中…(img-fKLxJLE0-1625050503638)]