干货 | 携程分布式图数据库Nebula Graph运维治理实践

最新推荐文章于 2024-03-14 11:27:34 发布

原创

最新推荐文章于 2024-03-14 11:27:34 发布 · 3k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #大数据 #分布式 #java #人工智能

本文介绍了携程如何选择并运维分布式图数据库Nebula Graph，包括选择原因、集群部署方式、中间件及运维管理的改进、系统调优实践和未来规划。文章详细阐述了在蓝绿部署、读写分离、流量分配等方面的客户端优化，并分享了在处理集群稳定性问题上的经验。

作者简介

Patrick Yu，携程云原生研发专家，关注非关系型分布式数据存储及相关技术。

一、背景

随着互联网世界产生的数据越来越多，数据之间的联系越来越复杂层次越来越深，人们希望从这些纷乱复杂的数据中探索各种关联的需求也在与日递增。为了更有效地应对这类场景，图技术受到了越来越多的关注及运用。

DB-ENGINES 趋势报告显示图数据库趋势增长遥遥领先

在携程，很早就有一些业务尝试了图技术，并将其运用到生产中，以Neo4j和JanusGraph为主。2021年开始，我们对图数据库进行集中的运维治理，期望规范业务的使用，并适配携程已有的各种系统，更好地服务业务方。经过调研，我们选择分布式图数据库Nebula Graph作为管理的对象，主要基于以下几个因素考虑：

1）Nebula Graph开源版本即拥有横向扩展能力，为大规模部署提供了基本条件；

2）使用自研的原生存储层，相比JanusGraph这类构建在第三方存储系统上的图数据库，性能和资源使用效率上具有优势；

3）支持两种语言，尤其是兼容主流的图技术语言Cypher，有助于用户从其他使用Cypher语言的图数据库（例如Neo4j）中迁移；

4）拥有后发优势（2019起开源），社区活跃，且主流的互联网公司都有参与（腾讯，快手，美团，网易等）；

5）使用技术主流，代码清晰，技术债较少，适合二次开发；

二、Nebula Graph架构及集群部署

Nebula Graph是一个分布式的计算存储分离架构，如下图：

其主要由Graphd，Metad和Storaged三部分服务组成，分别负责计算，元数据存取，图数据（点，边，标签等数据）的存取。在携程的网络环境中，我们提供了三种部署方式来支撑业务：

2.1 三机房部署

用于满足一致性和容灾的要求，优点是任意一个机房发生机房级别故障，集群仍然可以使用，适用于核心应用。但缺点也是比较明显的，数据通过raft协议进行同步的时候，会遇到跨机房问题，性能会受到影响。

2.2 单机房部署

集群所有节点都在一个机房中，节点之间通讯可以避免跨机房问题（应用端与服务端之间仍然会存在跨机房调用），由于机房整体出现问题时该部署模式的系统将无法使用，所以适用于非核心应用进行访问。

2.3 蓝绿双活部署

在实际使用中，以上两种常规部署方式并不能满足一些业务方的需求，比如性能要求较高的核心应用，三机房的部署方式所带来的网络损耗可能会超出预期。根据携程酒店某个业务场景真实测试数据来看，本地三机房的部署方式延迟要比单机房高50%+，但单机房部署无法抵抗单个IDC故障，此外还有用户希望能存在类似数据回滚的能力，以应对应用发布，集群版本升级可能导致的错误。

考虑到使用图数据库的业务大多数据来自离线系统，通过离线作业将数据导入到图数据库中，数据一致的要求并不高，在这种条件下使用蓝绿部署能够在灾备和性能上得到很好的满足。

与此同时我们还增加了一些配套的辅助功能，比如：

分流：可以按比例分配机房的访问，也可以主动切断对某个机房的流量访问
灾备：在发生机房级故障时，可自动切换读访问的流量，写访问的流量切换则通过人工进行操作

蓝绿双活方式是在性能、可用性、一致性上的一个折中的选择，使用此方案时应用端架构也需要有更多的调整以配合数据的存取。

生产上的一个例子：

三机房情况

蓝绿部署

三、中间件及运维管理

我们基于k8s crd和operator来进行Nebula Graph的部署，同时通过服务集成到现有的部署配置页面和运维管理页面，来获得对pod的执行和迁移的控制能力。基于sidecar模式监控收集Nebula Graph的核心指标并通过telegraf发送到携程自研的Hickwall集中展示，并设置告警等一系列相关工作。

此外我们集成了跨机房的域名分配功能，为节点自动分配域名用于内部访问（域名只用于集群内部，集群与外部连通是通过ip直连的），这样做是为了避免节点漂移造成ip变更，影响集群的可用性。

在客户端上，相比原生客户端，我们主要做了以下几个改进和优化：

3.1 Session管理功能

原生客户端Session管理比较弱，尤其是2.x早期几个版本，多线程访问Session并不是线程安全的，Session过期或者失效都需要调用方来处理，不适合大规模使用。同时虽然官方客户端创建的Session是可以复用的，并不需要release，官方也鼓励用户复用，但是却没有提供统一的Session管理功能来帮助用户复用，因此我们增加了Session Pool的概念来实现复用。

其本质上是管理一个或多个Session Object Queue，通过borrow-and-return的方式（下图），确保了一个Session在同一时间只会由一个执行器在使用，避免了共用Session产生的问题。同时通过对队列的管理，我们可以进行Session数量和版本的管理，比如预生成一定量的Session，或者在管理中心发出消息之后变更Session的数量或者访问的路由。