ElasticSearch这些坑记得避开 _生活百科

一、管理方式
二、结构维护
三、数据调度
- 1、同步方案
- 2、中断和恢复
四、刷新策略
五、深度分页
六、参考源码

Index用不好，麻烦事不会少；

一、管理方式【ElasticSearch这些坑记得避开】ElasticSearch作为最常用的搜索引擎组件，在系统架构中发挥极其重要的能力，可以极大的提升数据的加载和检索效率；但不可否认的是，在长期的应用实践中，也发现很多不好处理的流程和场景；

文章插图
从直观感觉上说，业务中对索引的使用主要涉及如图的几个流程，其核心也就是索引的结构维护与数据的流动管理两个模块；
如果数据结构比较简单且体量小，那么使用起来可能很顺手；如果数据主体复杂且会动态扩展，并且体量偏大，那么就很容易踩中一些比较坑的点；
比如：索引中字段一旦有误，调整的流程十分复杂；数据流向索引中的方式，需要根据场景灵活选择；以及数据查询时的深度分页问题；下面将围绕这些问题来总结下应对策略；
顺带补充一句，其实很多组件在应用的时候都有不太符合预期的地方，所以在集成时可以考虑编写自定义的管理程序，来解决使用时可能存在的问题；
二、结构维护对于ES索引的结构维护，数据主体如果相对简单的话，可以考虑手动管理，但实际上使用索引时，通常主体结构都比较复杂，字段个数超过三五十都很常见，所以基于流程化的管理很有必要；

文章插图
结构映射：将需要构建索引的主体结构，在字段库中统一维护，值得注意的是字段名称和类型，字段可以与关系型数据库的查询一致，但是不同组件类型的描述不一样，尤其对ES来说，如果字段类型不合理，会影响搜索的使用；
索引结构：在实际的业务场景中，字段的信息是会动态变化的，这就会给索引结构的维护带来很多麻烦，字段的增减都好管理，但是如果涉及类型的变动，则存在索引重建的过程，会导致数据多次重新调度，这也是风险较高的操作；
程序维护：这种结构维护的机制，其核心目的是把整个流程进行程序化管理，避免人工进行干预，以此来确保索引结构的稳定扩展；
不得不提的一个经验教训，曾经在管理业务日志的索引结构时，出现过一次误删动作，好在可以重新构建和数据备份恢复，但是依旧给心里留下了几厘米的阴影，此后也将维护流程彻底程序化，避免失误动作发生；
三、数据调度1、同步方案数据的调度管理，其本质就是将数据从一个容器向另一个容器搬运或者拷贝，其核心操作就是读和写两个动作，但是为了让流程具备容错和稳定性，通常需要做策略和方案的设计；

文章插图
同步双写：对数据的实时性要求极高，通常在一个事务中完成数据的双写动作，保证数据层面的强一致性；
异步解耦：在完成数据库的写动作之后，基于MQ消息解耦索引的写入，流程存在轻微的延迟，如果消费失败会导致数据缺失；
定时任务：通过任务调度的方式，以指定的时间周期执行新增数据的同步机制，存在明显的时效问题；
组件同步：采用合适的同步组件，比如官方提供的组件或者一些第三方开源的组件，在原理上与任务同步类似；
数据同步的选型方案有多种，如何选择完全看具体的场景，在过往的使用过程中，对于核心业务会采用同步双写，对于内部的活动类业务会采用异步的方式，对于业务日志会采用任务调度，对于系统的监控或执行日志则多是依赖同步组件；
2、中断和恢复无论采用何种方式将数据同步到索引中，都不得不面对一个灵魂问题，如果流程突然异常中断，恢复后如何保证索引数据不丢失？这个问题适应于很多复杂的流程；

文章插图
容错性是衡量一个复杂流程的核心指标，比如在索引数据同步的过程，需要短暂性的暂停，或者流程被迫中断时，都应该具备恢复后自动修复索引中数据缺失的能力；
ES实践中一个非常经典的问题，修改索引的结构时需要进行索引重建，此时要将当前索引迁入临时索引中，在完成索引结构调整之后，需要从临时索引中迁回数据，在此过程中，可以对服务交互的索引名称动态调整；