当前位置：网站首页>滴滴 Elasticsearch 集群跨版本升级与平台重构之路

滴滴 Elasticsearch 集群跨版本升级与平台重构之路

2020-11-06 01:15:41 【InfoQ】

导读： 前不久，滴滴ES团队将维护的30多个ES集群，3500多个ES节点，8PB的数据，从2.3.3跨大版本无缝升级到6.6.1。在对用户查询写入基本零影响和改动的前提下，解决了ES跨大版本协议不兼容、文件格式不兼容、mapping不兼容等难题，整个过程对绝大部分用户完全透明。同时还完成了Arius的架构升级，取得了单机查询性能提升40%，整体集群cpu下降10%，写入tps提升30%，集群资源使用率提升20%、0故障、运维成本下降60%的成绩。

本文将系统的介绍滴滴在从2.3.3跨大版本升级到6.6.1过程中的遇到的问题和解决方案，以及在搜索平台建设过程中的体系化思考。

01 背景介绍

1. 集群规模

目前滴滴使用的ES版本是2.3.3，集群个数有40多个，节点规模有3500+，集群总容量有8PB。

2. 业务规模

1200多个平台应用方在使用ES，30多个核心应用在使用ES，写入的TPS有1500W，查询的QPS有25W。

02 问题分析

针对以上规模的ES集群，从2.3.3升级到6.X版本，小版本会根据最后分析的结果确定，需要对潜在可能的问题进行分析和区分。

1. 问题分析

主要先从四大问题域进行区分分析：

  • 引擎侧：由于从2.3.3升级到6.X版本，版本差距过大，在文件格式和协议上都不兼容，因此无法进行原地滚动直接升级，需要双写搬迁升级，这样会耗费大量的机器去参与其中
  • 用户侧：6.X版本开始逐渐的不支持TCP接口，因此需要用户适配和升级；查询和返回值也有一定差异，如果用户侧做适配，会极大影响升级的进度
  • 资源侧：由于无法直接原地滚动直接升级，需要双写使用大量的机器，但是无法提供升级所需要的机器，如果升级过程中资源无法得到保障，那也会极大影响升级的进度
  • 操作侧：新版本的多集群如何进行运维管控？升级的结果如何验证？查询的效率和质量如何保障和保证的？这些问题都需要考虑

原文链接:【https://www.infoq.cn/article/J6BFzWfJA0cbmgzN7R1w】。未经作者许可，禁止转载。

版权声明
本文为[InfoQ]所创，转载请带上原文链接，感谢
https://www.infoq.cn/article/J6BFzWfJA0cbmgzN7R1w?utm_source=rss&utm;_medium=article

边栏推荐

猜你喜欢

随机推荐