Elasticsearch系列---实战零停机重建索引

前言

我们使用Elasticsearch索引文档时，最理想的情况是文档JSON结构是确定的，数据源源不断地灌进来即可，但实际情况中，没人能够阻拦需求的变更，在项目的某个版本，可能会对原有的文档结构造成冲击，增加新的字段还好，如果要修改原有的字段，只能重建索引了。

概要

本篇以实战方式讲解如何零停机完成索引重建的三种方案。

外部数据导入方案

整体介绍

系统架构设计中，有关系型数据库用来存储数据，Elasticsearch在系统架构里起到查询加速的作用，如果遇到索引重建的操作，待系统模块发布新版本后（若重建索引不是因为客户端修改导致的，可以不停机发版，直接操作），可以从数据库将数据查询出来，重新灌到Elasticsearch即可。

执行步骤

建议的功能方案：数据库 MQ 应用模块 Elasticsearch，可以在MQ控制台发送MQ消息来触发重导数据，按批次对数据进行导入，整个过程异步化处理，请求操作示意如下所示：

详细操作步骤：

1. 通过MQ的web控制台或cli命令行，发送指定的MQ消息
2. MQ消息被微服务模块的消费者消费，触发ES数据重新导入功能
3. 微服务模块从数据库里查询数据的总数及批次信息，并将每个数据批次的分页信息重新发送给MQ消息，分页信息包含查询条件和偏移量，此MQ消息还是会被微服务的MQ消息者接收处理。
4. 微服务根据接收的查询条件和分页信息，从数据库获取到数据后，根据索引结构的定义，将数据组装成ES支持的JSON格式，并执行bulk命令，将数据发送给Elasticsearch集群。

这样就可以完成索引的重建工作。

方案特点

MQ中间件的选型不做具体要求，常见的rabitmq、activemq、rocketmq等均可。

在微服务模块方面，提供MQ消息处理接口、数据处理模块需要事先开发的，一般是创建新的索引时，配套把重建的功能也一起做好。整体功能共用一个topic，针对每个索引，有单独的结构定义和MQ消息处理tag，代码尽可能复用。处理的批次大小需要根据实际的情况设置。

微服务模块实例会部署多个，数据是分批处理的，批次信息会一次性全部先发送给MQ，各个实例处理的数据相互不重叠，利用MQ消息的异步处理机制，可以充分利用并发的优势，加快数据重建的速度。

方案缺点

1. 对数据库造成读取压力，短时间内大量的读操作，会占用数据库的硬件资源，严重时可能引起数据库性能下降