企业品牌类网站有哪些,医院网站建设的意义,网站后台安全,网站建设公司 选中企动力公司Elasticsearch 是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎#xff0c;其每个字段均可被索引#xff0c;且能够横向扩展至数以百计的服务器存储以及处理TB级的数据#xff0c;其可以在极短的时间内存储、搜索和分析大量的数据。 滴滴ES发展至今#xf… Elasticsearch 是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎其每个字段均可被索引且能够横向扩展至数以百计的服务器存储以及处理TB级的数据其可以在极短的时间内存储、搜索和分析大量的数据。 滴滴ES发展至今承接了公司绝大部分端上检索和日志场景包括地图POI检索、订单检索、客服、内搜及把脉ELK场景等。 近几年围绕稳定性、成本、效率和数据安全这几个方向持续探索 滴滴ES有很多在线P0级检索场景为了提升集群稳定性我们自研了跨数据中心复制能力实现多机房数据写入强一致性并配合管控平台让ES支持多活能力为了提升查询性能和解决查询毛刺问题我们在7.6版本上原地升级支持JDK 17ES日志场景每天写入量在5PB-10PB量级写入压力和业务成本压力大为了提升ES的写入性能我们让ES支持ZSTD压缩算法由于ES索引里包含很多敏感数据我们又完善了ES的安全认证能力。 基于以上探索我们总结了一定的经验现分成4篇文章详细介绍。本篇文章介绍滴滴ES如何实现索引的跨数据中心复制从而保证索引的高可用。 滴滴跨数据中心复制能力 - Didi Cross Datacenter Replication由滴滴自研简称DCDR它能够将数据从一个 Elasticsearch 集群原生复制到另一个 Elasticsearch 集群。如图所示DCDR工作在索引模板或索引层面采用主从索引设计模型由Leader索引主动将数据push到Follower索引从而保证了主从索引数据的强一致性。 DCDR跨数据中心复制能力图 DCDR在滴滴内部的主要生产应用如下 灾难恢复DR/高可用性HA如果主集群发生故障能够通过切换主从集群快速恢复从而实现异地多活索引迁移索引可以在不同集群间迁移保证集群间的数据均衡同时实现索引在集群级别的分级保障主从查询隔离由于主从索引的强一致性保证配合自研ES Admin管控平台不同业务方可以查询不同的集群避免相互之间的查询影响 背景及目标 原生的Elasticsearch提供了集群内部的高可用能够保证集群内部的数据可靠性。但这种高可用无法满足对可靠性有进一步需求的用户。原生Elasticsearch主要有以下痛点 对于数据中心级别故障无法实现快速恢复数据在集群间搬迁成本很高需借助外部工具来完成多个复杂操作 最初滴滴内部应对跨数据中心的高可用借助了外部同步平台将数据双写到不同集群来实现。该方式依赖较重不支持历史数据同步并且无法保证主从索引数据的强一致性。随着外部平台的收敛双写的方式已经无法使用。ES 官方在6.7.0版本提供了跨集群数据复制功能该功能需付费且只能保证主从索引数据的最终一致性。滴滴内部核心业务如POI检索滴滴APP上下车地点检索服务、订单检索业务都要求主从索引数据强一致性。 为解决上述问题满足业务方诉求滴滴ES团队决定自研跨数据中心复制能力即上文的DCDR。 DCDR在设计时主要有以下几个目标 保证主从数据的强一致性保证高可用性快速实现灾难恢复实现不停机跨集群索引迁移可靠的版本升级Elasticsearch的Rolling upgrades和Full cluster restart upgrade方案都无法做到升级后回滚 技术基础 DCDR功能支持将远程集群中的索引复制到本地集群在复制过程中需要考虑两个重点实时数据的同步、历史数据的同步。实时数据同步依赖ES写入机制数据同步依赖ES副本恢复机制。因此在介绍DCDR的方案设计以及实现细节之前对这两个流程简单概述 基本写入机制 ES写入是先写主分片主分片写完后再将请求并行转发到副本副本处理完再由主分片返回写入结果具体流程如下注本文中Si代表ES具体分片P代表主分片R代表副本 副本恢复流程 为了保证数据副本的一致性副本的数据需要恢复到和主分片一致才能正常对外提供服务。ES的副本恢复是分片级别的分为主分片恢复流程和副分片恢复流程。由于ES的副本恢复流程极为复杂并且DCDR的数据恢复过程中仅与副分片恢复流程相关因此这里只简单地介绍下副分片恢复流程。 副本recovery的目标是要将本地数据恢复到和主分片一致主流程分为两个阶段 阶段一是主分片给副本发送segment文件存储的是已经落盘并解析后的具体数据阶段二是主分片向副本发送translog日志未落盘的数据类似mysql 的WAL Log两阶段结束后副本的恢复流程就结束了 具体流程如下图 方案设计 设计思想 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集群建索引后自动生成的随机字符串要怎么处理呢 综合考虑开发难度和源码侵入问题主从索引的索引名和UUID都保持一致在从索引创建时透传主索引的UUID到从集群从索引在创建索引时不再自动生成UUID解决从索引创建UUID不一致问题由于ES墓地会暂时保存被删除的索引因此在从索引创建时扫描ES墓地并删除UUID相同的索引解决从索引删除后无法重建问题 2、历史数据恢复 历史数据恢复方案在设计上借鉴了ES副本恢复策略。DCDR从索引的副本恢复同样是分片级别的也需要进行segement和translog的复制环节。历史数据恢复发生的条件 新建DCDR链路从索引需要根据主索引进行历史数据恢复从索引分片数据写入失败主索引定时任务重建DCDR链路 从索引作为远程副本在历史数据恢复方面和ES的副本恢复流程基本是一致的主要区别图中绿色标记在于第1步的数据恢复触发条件以及第6步加入的副本组不同。同时要注意以下设计细节 Q怎么触发历史数据的恢复 ES的副本恢复是由集群状态变更事件驱动的从索引的恢复是跨集群的因此只能依靠主集群的RPC调用触发从集群的DCDR历史数据恢复。 QES分片恢复是个很耗时的阶段如何提高从索引的分片恢复效率使得从索引能够快速提供服务 从索引只需要恢复自身的主分片数据之后DCDR从索引历史数据恢复结束从索引就能正常接收主索引的写请求了。从索引自身的副本恢复依赖于从集群的ES副本机制即可。这样能够极大地降低DCDR链路历史数据恢复时间。 Q从索引什么时候可以正常接收主索引的写请求呢 ES副本会在主分片phase1结束副本启动Engine后加入主分片副本组开始接收主分片的写请求。从索引的恢复也是类似的从索引的主分片作为主索引对应主分片的远程副本也会在主索引主分片phase1结束后自身Engine启动后由主索引的对应主分片加入远程副本组开始接收写请求。远程副本组的实现是在ES的ReplicationGroup类中增加一个远程的prepared list。 QDCDR历史数据恢复过程中主索引的主分片能否迁移 分片搬迁是集群均衡的一种手段由于DCDR的恢复是跨集群的无法通过集群状态变更快速地感知到分片迁移并进行处理。因此主分片不能迁移。在DCDR数据恢复过程中会通过加锁的方式防止主分片迁移。 3、实时数据同步 实时数据同步指的是历史数据同步完成后增量数据如何同步到从索引。根据前文的ES写入流程可知ES写入是先写主分片之后再将写请求同步转发到副本上。基于滴滴内部业务场景考虑需要异地多活的业务数据写入量一般不大远未达到ES的写入瓶颈并且一些核心业务对数据一致性有强依赖。因此DCDR在实时数据同步上采用主分片写入成功将数据同步转发给副本以及远程副本这一方案。该方案牺牲一定的数据写入性能从而保证了数据的强一致性。 实时数据同步策略采用的是将写请求转发到远程副本实现的仍然有许多细节需要考虑 Q远程副本写入失败怎么办 ES副本写入失败的处理策略是将副本从同步副本组移除并重新执行Recovery。远程副本写入失败的处理策略和ES副本写入失败处理策略类似是将远程副本从主索引主分片的远程副本组中移除主索引将不再转发写请求到从索引由从索引的定时检查机制重新执行数据恢复流程。 Q从索引的seq_num每条请求递增的唯一ID用来加快副本恢复流程的如何保证主从一致 从索引的分片采用了自定义的Engine该Engine能够直接接收主索引传过来的seq_num不再生成seq_num值。 Q主从mapping如何保证一致要更新mapping时怎么处理 新建DCDR链路时会将主索引的mapping拷贝到从集群并新建从索引保证链路新建时主从索引的mapping是一致的。DCDR的设计思想是远程副本策略是将写请求直接转发给从索引。因此后期如果出现需要更新mapping的字段会由主从集群各自的master去执行master任务去更新mapping即可主从master mapping更新处理策略一致。 4、主从索引数据质量校验 数据质量校验环节是从索引数据可靠性的保障。它会定时检查集群状态中的DCDR元信息是否和当前链路运行状态一致根据结果对链路进行相应的操作。当主从索引数据差距过大或链路异常时主集群会主动断开链路并通知从索引进行差量数据恢复。ES集群中MasterNode负责管控集群元数据因此在设计校验任务时主要用于链路元数据创建及检查从索引是否存在DataNode负责数据存储因此用于判断主从分片是否需要进行数据恢复。 5、其他 经过以上4个环节就能将数据从一个 Elasticsearch 集群原生复制到另一个 Elasticsearch 集群搭配上主从切换策略就能在保证数据强一致性的前提下实现跨集群高可用。对于不停机跨集群索引迁移这一目标我们通过DCDR将数据同步到目的端集群等待存量数据恢复完成再进行一次主从切换。对于可靠的版本升级这一目标我们通过DCDR复制待升级版本数据到备用集群当版本升级异常时能够快速切换集群。 总结 目前滴滴ES共有6个DCDR从集群建立的DCDR模板链路400DCDR索引链路2000涵盖了POI、dos_order、soda等滴滴核心业务。目前ES仍然存在查询毛刺、查询相互影响、分片恢复、写入性能等方面问题后续我们会在这些方面重点发力更好的助力业务发展。
