Elasticsearch 是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎，其每个字段均可被索引，且能够横向扩展至数以百计的服务器存储以及处理TB级的数据，其可以在极短的时间内存储、搜索和分析大量的数据。

滴滴ES发展至今，承接了公司绝大部分端上检索和日志场景，包括地图POI检索、订单检索、客服、内搜及把脉ELK场景等。

近几年围绕稳定性、成本、效率和数据安全这几个方向持续探索：

基于以上探索，我们总结了一定的经验，现分成4篇文章详细介绍。本篇文章介绍滴滴ES如何实现索引的跨数据中心复制从而保证索引的高可用。

滴滴跨数据中心复制能力 - Didi Cross Datacenter Replication，由滴滴自研，简称DCDR，它能够将数据从一个 Elasticsearch 集群原生复制到另一个 Elasticsearch 集群。如图所示，DCDR工作在索引模板或索引层面，采用主从索引设计模型，由Leader索引主动将数据push到Follower索引，从而保证了主从索引数据的强一致性。

DCDR跨数据中心复制能力图

DCDR在滴滴内部的主要生产应用如下：

原生的Elasticsearch提供了集群内部的高可用，能够保证集群内部的数据可靠性。但这种高可用无法满足对可靠性有进一步需求的用户。原生Elasticsearch主要有以下痛点：

最初，滴滴内部应对跨数据中心的高可用，借助了外部同步平台将数据双写到不同集群来实现。该方式依赖较重，不支持历史数据同步，并且无法保证主从索引数据的强一致性。

随着外部平台的收敛，双写的方式已经无法使用。ES 官方在6.7.0版本提供了跨集群数据复制功能，该功能需付费且只能保证主从索引数据的最终一致性。滴滴内部核心业务，如POI检索（滴滴APP上下车地点检索服务）、订单检索业务，都要求主从索引数据强一致性。

为解决上述问题，满足业务方诉求，滴滴ES团队决定自研跨数据中心复制能力，即上文的DCDR。

DCDR在设计时主要有以下几个目标：

DCDR功能支持将远程集群中的索引复制到本地集群，在复制过程中需要考虑两个重点：实时数据的同步、历史数据的同步。实时数据同步依赖ES写入机制，数据同步依赖ES副本恢复机制。因此，在介绍DCDR的方案设计以及实现细节之前，对这两个流程简单概述：

ES写入是先写主分片，主分片写完后再将请求并行转发到副本，副本处理完再由主分片返回写入结果，具体流程如下：（注：本文中Si代表ES具体分片，P代表主分片，R代表副本）       

为了保证数据副本的一致性，副本的数据需要恢复到和主分片一致才能正常对外提供服务。ES的副本恢复是分片级别的，分为主分片恢复流程和副分片恢复流程。由于ES的副本恢复流程极为复杂，并且DCDR的数据恢复过程中仅与副分片恢复流程相关，因此这里只简单地介绍下副分片恢复流程。

副本recovery的目标是要将本地数据恢复到和主分片一致，主流程分为两个阶段：

具体流程如下图：     

DCDR的核心思想是将从索引对应分片看做主索引对应分片的一个远程副本来处理。如下图，从索引的shard0主分片，会被当做主索引shard0主分片的一个远程副本。            

为了让大家更好地理解这个思路，简单介绍下远程副本：远程副本是由ES数据副本模型延伸而来，由主索引的主分片保存远程副本相关元数据，在实现上借鉴了微软的PacificA算法。该设计思想符合ES数据副本模型，能够极大程度地复用ES副本逻辑，降低开发难度，减少对开源ES内核的侵入。

以下是该算法的部分核心术语和ES数据副本模型的对应关系：

DCDR是跨集群数据复制能力，实现该功能的第一步就是需要明确哪些索引模板或者索引需要进行数据的跨集群复制，也就是需要建立起DCDR链路。其次，DCDR的从索引作为一个远程副本，需要恢复到和主索引的数据一致才能正常提供服务，即历史数据恢复。从索引的数据恢复到和主索引一致，当主索引新增数据时，数据该如何写入从索引，即实时数据同步。经过以上环节，从索引就能够正常提供服务，那么如何保证数据的可靠性呢？这就涉及到了主从索引数据质量校验。

基于以上思考，整个DCDR的方案设计上分为四个主流程：

1）DCDR链路构建

ES集群是基于集群状态驱动的，因此DCDR链路构建的本质就是改变集群状态，并在对应机器上应用新的集群状态。滴滴内部的ES使用方式是索引模板形式（一组拥有相同前缀的索引集合），因此在链路设计上需要支持模板链路和索引链路。DCDR链路集群元信息通过ES cluster state自定义metaData实现，链路拥有统一的命名规则，并且区分模板和索引，主要信息展示如下：

模板链路：{   "templates": {       "templateA_to_ClusterA": {           "name": "IndexA_to_ClusterA", // dcdr模板链路名           "template": "templateA",               // 索引模板名           "replica_cluster": "ClusterA"    // 从集群名称       }   }}索引链路：{   "Index_202206/Index_202206(ClusterA)": {       "primary_index": "Index_202206", // 主索引名称       "replica_index": "Index_202206", // 从索引名称       "replica_cluster": "ClusterA", // 从集群名称       "replication_state": true            // 链路状态   }}

ES集群对外提供了DCDR链路创建API，通过API将链路元信息更新到集群状态中，DCDR相关模块通过订阅集群状态变更事件，从而进入数据同步流程。如下图：         

有个设计细节需要注意：

Q：主从索引名是一致的，那么主从索引的唯一标识UUID（集群建索引后自动生成的随机字符串）要怎么处理呢？

2）历史数据恢复

历史数据恢复方案在设计上借鉴了ES副本恢复策略。DCDR从索引的副本恢复同样是分片级别的，也需要进行segement和translog的复制环节。历史数据恢复发生的条件：

从索引作为远程副本在历史数据恢复方面和ES的副本恢复流程基本是一致的，主要区别（图中绿色标记）在于第1步的数据恢复触发条件，以及第6步加入的副本组不同。同时要注意以下设计细节：

Q：怎么触发历史数据的恢复？

Q：ES分片恢复是个很耗时的阶段，如何提高从索引的分片恢复效率，使得从索引能够快速提供服务？

Q：从索引什么时候可以正常接收主索引的写请求呢？

Q：DCDR历史数据恢复过程中，主索引的主分片能否迁移？

3）实时数据同步

实时数据同步指的是历史数据同步完成后，增量数据如何同步到从索引。根据前文的ES写入流程可知，ES写入是先写主分片，之后再将写请求同步转发到副本上。基于滴滴内部业务场景考虑，需要异地多活的业务数据写入量一般不大，远未达到ES的写入瓶颈，并且一些核心业务对数据一致性有强依赖。

因此，DCDR在实时数据同步上采用主分片写入成功，将数据同步转发给副本以及远程副本这一方案。该方案牺牲一定的数据写入性能，从而保证了数据的强一致性。

实时数据同步策略采用的是将写请求转发到远程副本实现的，仍然有许多细节需要考虑：

Q：远程副本写入失败怎么办？

Q：从索引的seq_num（每条请求递增的唯一ID，用来加快副本恢复流程的）如何保证主从一致？

Q：主从mapping如何保证一致？要更新mapping时怎么处理？

4）主从索引数据质量校验

数据质量校验环节是从索引数据可靠性的保障。它会定时检查集群状态中的DCDR元信息是否和当前链路运行状态一致，根据结果对链路进行相应的操作。当主从索引数据差距过大或链路异常时，主集群会主动断开链路，并通知从索引进行差量数据恢复。

ES集群中，MasterNode负责管控集群元数据，因此在设计校验任务时，主要用于链路元数据创建及检查从索引是否存在；DataNode负责数据存储，因此用于判断主从分片是否需要进行数据恢复。   

5）其他

经过以上4个环节就能将数据从一个 Elasticsearch 集群原生复制到另一个 Elasticsearch 集群，搭配上主从切换策略，就能在保证数据强一致性的前提下实现跨集群高可用。对于不停机跨集群索引迁移这一目标，我们通过DCDR将数据同步到目的端集群，等待存量数据恢复完成，再进行一次主从切换。对于可靠的版本升级这一目标，我们通过DCDR复制待升级版本数据到备用集群，当版本升级异常时能够快速切换集群。

目前滴滴ES共有6个DCDR从集群，建立的DCDR模板链路400+，DCDR索引链路2000+，涵盖了POI、dos_order、soda等滴滴核心业务。目前ES仍然存在查询毛刺、查询相互影响、分片恢复、写入性能等方面问题，后续我们会在这些方面重点发力，更好的助力业务发展。