2、中断和恢复无论采用何种方式将数据同步到索引中，都不得不面对一个灵魂问题，如果流程突然异常中断，恢复后如何保证索引数据不丢失？这个问题适应于很多复杂的流程；
文章插图
容错性是衡量一个复杂流程的核心指标，比如在索引数据同步的过程，需要短暂性的暂停，或者流程被迫中断时，都应该具备恢复后自动修复索引中数据缺失的能力；
ES实践中一个非常经典的问题，修改索引的结构时需要进行索引重建，此时要将当前索引迁入临时索引中，在完成索引结构调整之后，需要从临时索引中迁回数据，在此过程中，可以对服务交互的索引名称动态调整；
文章插图
当然也可以直接使用临时索引作为交互索引，避免一次迁移动作，这种动态的识别需要在服务中嵌入，在整个
reindex过程中要避免手动干预，个人还是更相信程序的安全性和准确性；四、刷新策略在向ES索引中写数据时，存在三种不同的数据刷新机制，查看
6.8版本的设置中，参数refresh_interval设置的是1s时间，即执行写入动作1秒后数据才可以被搜索到，避免频繁写入消耗过多的资源；NONE：默认的刷新策略，请求提交之后不会等待数据刷新，降低资源消耗但数据实时性低；
IMMEDIATE：请求提交后立即刷新索引，数据的实时性很高但是资源消耗过大，API文档中建议测试使用；
WAIT_UNTIL：请求提交之后会等待索引刷新完成才会结束，相对来说是一种比较平衡的策略；
刷新机制对于索引的数据维护来说，主要在增删改的动作中，对即时查询有直接的影响，至于如何选择还是要结合具体的场景，尤其与同步方案关联密切，也可以在索引交互中动态维护策略，来应对不时之需；
五、深度分页对于数据查询来说，几乎都存在分页的需求，在常见的应用中，不断下拉的功能都是存在最大的极限值；
ES中常用From/Size进行分页查询，但是存在一个限制，在索引的设置中存在
max_result_window分页深度的限制，6.8版本默认值是10000条，即10000之后的数据无法使用From/Size翻页；先从实际应用场景来分析，大多数的翻页需求最多也就前10页左右，所以从这个角度考虑，ES的翻页限制在合理区间，在实践中也存在对部分索引调高的情况，暂未出现明显问题；
再从技术角度来思考一下，如果翻页的参数过大意味着更多的数据过滤，那计算资源的占用也会升高，ES引擎的强大在于搜索能力，检索出符合要求的数据即可；
文章插图
不管是ES还是其它类似的分布式存储组件，甚至是MySQL分库分表模式，其本质都是数据分布在不同服务节点的不同数据片上；常规的执行原理都是给请求分配一个主节点，协调各个节点执行相同的查询，并完成结果汇总和响应，深度分页时计算资源的占用自然非常高；
如果一定需要深度分页，在
6.8的版本中提供了Scroll或Search-After两种其他的方式，用法参考相关文档即可 。六、参考源码
编程文档：https://gitee.com/cicadasmile/butte-java-note应用仓库：https://gitee.com/cicadasmile/butte-flyer-parent
经验总结扩展阅读
- 胆固醇高怎么办 降胆固醇多吃这些食物
- 恭喜这些锦鲤星座 11月起运势飙升元气满满
- 交管12123有哪些使用功能 这些功能要了解
- 索尼液晶电视机怎么安装软件 你是否注意到了这些
- 使用 StringUtils.split 的坑
- 2022年立冬后天坑在哪个方位
- ? 海信电视机哪个系列好 选这些准没错
- 京东云开发者｜ElasticSearch降本增效常见的方法
- 探望坐月子的礼物排行榜，送宝宝和产妇这些最有心意
- 记录在linux上单机elasticsearch8和kibana8