
> 导读：「分布式锁」技术科普系列，由 NebulaGraph 存储负责人 @critical27 整理自己的“学习笔记”而成。在单体应用中我们通过锁实现共享资源访问，而在分布式系统中，则通过分布式锁解决。NebulaGraph 作为一款分布式图数据库，邀请大家一起学习分布式系统架构中的分布式锁～


![](https://pic1.zhimg.com/80/v2-d555f7b4514545baf26266e355165dad_1440w.jpg?source=d16d100b)




🔍在开始本期的学习之间，推荐阅读⬇️

[技术科普｜深入理解分布式锁的原理与实现 part 1](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516628&idx=1&sn=ae7ed7051c882f9208946f872116245e&scene=21#wechat_redirect)

上期文末卖了个关子：当 Redlock 提出之后，DDIA 的作者 Martin Kleppman 质疑了这个算法，后来 Redis 的作者 Antirez 也下场进行了反驳。

两个人都是大牛，到底谁说的更有道理呢？本期来看看大牛们如何理解分布式锁。

# 一、Argues about Redlock

在 Redlock 提出之后，Designing Data-Intensive Applications 的作者 Martin Kleppmann 就在博客《How to do distributed locking》提出了质疑，Redlock 也作为一个反例被写进了这本书里（只不过没有点名是 Redlock）。

Martin Kleppmann 举了一个反例，客户端 1 在获取到分布式锁之后操作共享资源之前，发生了 GC，而 GC 期间锁又过期了。此时客户端 2 也可以获取到分布式，进而出现了两个客户端同时操作共享资源的问题。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/lock1.webp)



**这里面 stop-the-world GC 只是一种客户端被阻塞的情况，比如文章中提到好几种可能：**

* GC: 任何 Garbage Collector 实现都可能需要 stop-the-world

* 操作共享资源时，发生了 network delay

* 发生 page fault，需要将硬盘上的数据加载进内存

* 进程收到了 SIGSTOP 或者 SIGPAUSE 信号

* 时钟漂移，甚至闰秒问题

除了上面的问题，Martin Kleppmann 还指出 Redlock 有以下缺陷，其核心在于 Redlock 是依赖于本地时间的比较来保证分布式锁互斥的。

**Redlock 主要有两个地方使用了本地时间，可以参照前文理解：**

* Redis 需要根据本地时间，决定记录的过期时间

* 客户端在获取锁成功之后，需要用两次本地之间的差值来计算锁的有效时间

Redis 使用  `gettimeofday` 来获取本地时间，这个时钟不是原子递增的，会出现时钟回退和漂移。因此，而 Redlock 却重度依赖于本地时间，又或者对网络延迟和超时时间做了时间上的假设，因此不是一个安全的分布式锁实现。

原文如下：

> "For algorithms in the asynchronous model this is not a big problem: these algorithms generally ensure that their safety properties always hold, without making any timing assumptions. Only liveness properties depend on timeouts or some other failure detector. In plain English, this means that even if the timings in the system are all over the place (processes pausing, networks delaying, clocks jumping forwards and backwards), the performance of an algorithm might go to hell, but the algorithm will never make an incorrect decision."
> 
> "However, Redlock is not like this. Its safety depends on a lot of timing assumptions: it assumes that all Redis nodes hold keys for approximately the right length of time before expiring; that the network delay is small compared to the expiry duration; and that process pauses are much shorter than the expiry duration."

博客里面举的一个反例如下，假设 ABCDE 组成一个 5 节点的 Redis 分布式锁集群：

* 客户端 1 获取到节点 A、B、C 上的锁

* 节点 C 上的时钟发生跳变（比如系统管理员突然把系统时间调大了），导致锁到期

* 客户端 2 此时就能获取节点 C、D、E 上的锁

* 客户端 1 和 2 都认为自己持有分布式锁

这个例子其实和 Redis 文档里面关于持久化一部分的例子几乎如出一辙，问题都出在其中一个节点在不超过 TTL 的时间内两次上锁成功。只不过文档中是节点发生了重启，而此处则是发生了时钟跳变。

**如果我们假设真的不会发生时钟跳变，那么套用前面的 GC，一样可以复现问题：**

* 客户端 1 向 A、B、C、D、E 发出上锁请求

* 客户端 1 在收到上锁的响应之前发生 GC，并一直卡住

* 所有节点锁都过期

* 客户端 2 获取锁成功

* 客户端 1 此时 GC 结束，收到之前上锁请求的响应，认为上锁成功

* 客户端 1 和 2 都认为自己持有分布式锁

**小结**

Martin Kleppmann 认为 Redlock 依赖于以下的假设：

* 有上限的网络延迟

* 有上限的进程暂停时间

* 有上限的时钟漂移

只要上面的任何一个假设在真实环境中不满足，Redlock 就不能保证 safety.

# 二、Fencing token

除此之外，Martin Kleppmann 提出了一个解决方案：每次分布式锁返回成功时，需要携带一个自增的 token. 客户端在操作共享资源时，需要携带这个 token. 而共享资源可以比较当前已经使用的最大 token，拒绝掉携带过期 token 的请求。通过每次生成的自增 token，去除了对本地时钟的依赖。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/lock2.webp)


比如还是前面的例子，客户端 1 获取了分布式锁，token 为 33，然后被 GC 阻塞住。客户端在锁过期之后获取了分布式锁，token 为34，并操作了共享资源。当客户端 1 恢复时，再用 token 为 33 发送请求时，会被共享资源拒绝。

然而 Redlock 本身的限制导致不能使用 fencing token 来解决这些问题，一个核心点就在于 Redlock 的多个 Redis 节点都是主库，并且互相不通信，因此各个节点之间很难生成一个一致的自增 token 返回给客户端。

# 三、Is Redlock safe?

Redis 的作者 Antirez 之后也进行了反驳：

> "In this analysis I’ll analyze Martin’s analysis so that other experts in the field can check the two documents (the analysis and the counter-analysis), and eventually we can understand if Redlock can be considered safe or not."

**Antirez 的文章总结下来有几个论点：**

**论点 1 ：Martin 提出的 fencing token 不是必须的**

这里需要从两个方面进行解释：

* 是不是自增 id 关系不大，比如 Redlock 使用`/dev/urandom`中的 20 个字节作为 uuid，也能够通过 read-modify-write 进行比较（冲突概率认为极低）。比如往 MySQL 中更新记录可以这么做：

UPDATE table T SET val = $new_val WHERE id = $id

* 如果共享资源已经能通过某种机制拒绝掉过期请求（比如上面写入 MySQL），这种情况下就不需要使用分布式锁，直接通过 MySQL 中的记录不就好了吗？通常使用分布式锁的时候，都是因为共享资源不能提供类似分布式锁的互斥能力，比如写一个文件。

Antirez 的原话如下，这个论点我是比较 buy-in 的。

> "I want to mention again that, what is strange about all this, is that it is assumed that you always must have a way to handle the fact that mutual exclusion is violated. Actually if you have such a system to avoid problems during race conditions, you probably don’t need a distributed lock at all, or at least you don’t need a lock with strong guarantees, but just a weak lock to avoid, most of the times, concurrent accesses for performances reasons."

**论点 2 ：其余问题不只是存在于 Redlock**

针对 Martin 博文中对 Redlock 不能应对 NPC 问题（Network delay, Process pause, Clock drift），Antirez 也进行了反驳。

首先是时钟漂移，Redlock 的确假设了各个时钟之间的速度是相近的，也就是时钟偏移量是有上限的，但 Antirez 认为这个时钟模型是符合现实情况的，事实上的确也如此。至于 Martin 文章中提到的时钟跳变，主要出现在两种情形：

* 系统管理源手动修改系统时间

* NTP 同步

> "The above two problems can be avoided by “1” not doing this (otherwise even corrupting a Raft log with “echo foo > /my/raft/log.bin” is a problem), and “2” using an ntpd that does not change the time by jumping directly, but by distributing the change over the course of a larger time span."

这的确也是一种解决的技术手段，不过这就对对 Redis 分布式锁进行运维的人员就有要求了，不是所有人都看到过这番争论的。

**论点 3 ：网络延迟和进程暂停相关问题**

首先 Antirez 回顾了下 Redlock 的基本流程：

1. Get the current time.

2. All the steps needed to acquire the lock.

3. Get the current time, again.

4. Check if we are already out of time, or if we acquired the lock fast enough.

5. Do some work with your lock.

在第一步和第三步分别获取了一次本地时间，如果 Network delay 和 Process pause 发生在了第一步和第三步之间，那通过两次本地时间的比较是能够发现的。而第一步和第三步的时间间隔也很短，因此时钟漂移的影响可以忽略不计，但时钟跳变只能按前面所说的方法进行规避了。

**这里举了一个例子：**

当客户端发送请求尝试获取锁时，服务端已经成功授权锁，并发送了响应。然而此时发生网络丢包或者重传，导致当客户端收到响应时候，服务端已经认为过期了。所以客户端在收到响应时，网络延迟早就发生了，客户端也无能为力。客户端能做的就是必须检查我还有多少时间可以用来操作共享资源，这个检查是所有带自动过期的分布式锁算法都需要的。

那么只有 Network delay 和 Process pause 发生在第三步以后，才可能出现问题。而 Antirez 再次强调这是所有分布式锁服务都会遇到的问题，即客户端认为获取锁成功，而服务端已经认为锁过期的情况。即便使用 ZooKeeper 来作为分布式锁也一样会遇到问题。

**这里简单介绍 ZooKeeper 是如何实现的分布式锁的。**

1. 客户端 1 和 2 都尝试创建临时节点 ZNode，例如 `/lock`

2. 假设客户端 1 请求先到达，则加锁成功，客户端 2 加锁失败

3. 客户端 1 操作共享资源

4. 客户端 1 删除`/lock`节点，释放锁

ZooKeeper 不像 Redis 那样，需要考虑锁的过期时间问题，它是采用了临时节点，保证客户端 1 拿到锁后，只要连接不断，就可以一直持有锁。ZooKeeper 的客户端在创建临时节点后，会在和服务端的 Session 中不断发送心跳来续约，保证服务端。如果客户端的心跳由于 crash 或者 GC 终端，那么这个临时节点会自动删除，保证了锁一定会被释放。

**我们把之前的异常套用在 ZooKeeper 上：**

1. 客户端 1 创建临时节点 `/lock`成功，拿到了锁

2. 客户端 1 发生 GC，并一直卡住

3. 客户端 1 无法给 Zookeeper 发送心跳，Zookeeper 认为过期把临时节点 `/lock` 删除

4. 客户端 2 创建临时节点 `/lock`成功，拿到了锁

5. 客户端 1 进程此时 GC 结束

6. 客户端 1 和 2 都认为自己持有分布式锁

因此，即便是使用 Martin 推荐的 ZooKeeper 来做分布式锁服务，也无法完全避免 NPC 的问题。

# 四、结论

双方其实说的都有道理，这更从侧面验证了实现一个分布式锁服务本质上就是要实现一致性共识。而一个通常意义下的分布式锁服务，是无法在极端情况下保证 safety 和 liveness 的。


---

**Reference**

[1]万字长文说透分布式锁：https://zhuanlan.zhihu.com/p/403282013

[2]Distributed Locks with Redis：https://redis.io/docs/latest/develop/use/patterns/distributed-locks

[3]Redis 实现分布式锁：https://juejin.cn/post/6975069367574888478

[4]How to do distributed locking：https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

[5]Is Redlock safe?：https://antirez.com/news/101

[6]Redis Redlock 的争论：https://juejin.cn/post/6976538149904678925

[7]Because Coordinating Distributed Systems is a Zoo:https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html

---

NebulaGraph 邀你参加开源之夏🌟⬇️

[开源之夏｜从 NebulaGraph 开启你的图数据库开源之旅！](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516493&idx=1&sn=cf0fac7165210fee057a889c77b6888b&scene=21#wechat_redirect)

 Redlock 提出之后，DDIA 的作者 Martin Kleppman 质疑了这个算法，后来 Redis 的作者 Antirez 也下场进行了反驳。到底谁说的更有道理呢？本期来看看大牛们如何理解分布式锁。

Redis 作者与 DDIA 作者激辩：Redlock 真的安全吗？

> 导读：如何提升 RAG 的效果？如何把 NebulaGraph 和大模型相结合？我们将用五期「星云实验室」，手把手教大家围绕知识图谱+GraphRAG, 从 0 到 1 搭建一款垂直领域 AI 应用。
> 
> 重点速览：
> 
> * 搭建 AI 环境
> 
> * 部署 NebulaGraph 图数据库

![](https://pic1.zhimg.com/80/v2-2bbe3a3d018e356f9d8c6f5f208136c9_1440w.jpg?source=d16d100b)




# 一、背景

“怎样提升 RAG 的效果？”、“为什么我做的 RAG 那么差？”、“检索不全啊，答非所问，怎么办？”......

从前端查询，到最后大模型的回答，其中的整个链路，充满变数与选择，传统意义的 RAG 非常容易做出来，但是能交付的，非常考究设计，而知识图谱便是重要一环。

知识图谱可以在一定程度上增强 RAG ：

## （一）找到的就是相关的

相似，不等于相关，比如我们做医疗 RAG 项目，心绞痛 ≠ 胆绞痛，二者虽有 2 个字相同，但是两个名词是完全不同概念。通过知识图谱查到的信息，找到的索引，它背后会通过相关的边，连接在一起。给大模型参照的信息中，还连带上多个节点形成的背景。

![](https://picx.zhimg.com/80/v2-61ae44c5a3bdf549752d821662685102_1440w.jpg?source=d16d100b) 

## （二）提升巨量数据检索性能

面对巨量的数据，大概到千万 tokens，系统陷入困惑，性能开始下降。因为相似的 tokens 太多了，无法定位到文本块，当然，通过多种的处理策略：文本块标签、查询扩写编排等手段可以解决问题，但做过的朋友就知道，这有多烦 Orz

知识图谱在数据处理层面，每个命中的节点背后，跟的是对应的问题，甚至你可以通俗理解：知识图谱是一个大文本块的节点集合，是相关的，所以才准。

# 二、搭建开发环境

**推荐搭建环境**

> 操作系统：Linux 
实操环境：miniconda/jupyter/docker 
cuda 版本：12.2及以上 
PyTorch：2.3 开发语言：Python 3.10 及以上 
知识图谱：NebulaGraph 
RAG 框架：LlamaIndex 或 LangChain 
本地大模型：Qwen2-7B（高并发 VLLM 部署，灵活自定义） 
嵌入索引模型：text2vec-large-chinese 
算力要求：无要求，3090*24G（完整体验）或 API 供应商

## （一）搭建 AI 环境

建议第一次使用 Linux 系统的同学，选择 win11+Ubuntu24 桌面版双系统，因为它们的系统交互逻辑是相似的，即使是没有用过 Linux 的朋友，也可快速上手。下载 Ubuntu 24.04.1 LTS 版本，安装时选择同步安装显卡驱动，因为已经安装了最新的驱动，所以下载后直接安装 cuda 即可，是匹配的，下载链接⬇️

https://ubuntu.com/download/desktop

部分依赖库，只有 Linux 版本，如果你不打算用 Linux 系统，必须在 WSL 环境下才能跑完全程。

### 1. cuda 安装

因为系统已经自带英伟达最新驱动，所以 cuda 安装就方便了，如果你没有选择安装驱动，处理比较麻烦，建议新手重新安装系统。

进入系统后，打开终端，执行以下命令安装 cuda，每一行就是一个执行命令：


```
# 先看看gcc是否正常安装
gcc --version
# 没装的先安装gcc，或者版本太低，都可以通过这个安装
sudo apt install gcc
# 更新Ubuntu
sudo apt update && sudo apt upgrade
# 安装cuda
sudo apt install nvidia-cuda-toolkit
# 安装完后，重启系统
reboot
# 查看是否安装成功
nvcc --version
```

### 2. 安装 miniconda

这是一个环境管理工具，每一个环境都是独立的，避免了不同环境的依赖冲突问题。同时这也是学习 AI 必须要会的工具，如果你习惯其他环境管理工具，可以用自己熟悉的，如果是刚开始学，建议跟着我们来实操。


```
# 创建一个文件夹，稍后存放下载的安装文件
mkdir -p ~/miniconda3
# 下载miniconda
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda3/miniconda.sh
# 安装，需要一直点回车，看到输入yes/no时，输入yes，回车
bash ~/miniconda3/miniconda.sh -b -u -p ~/miniconda3
# 删除安装包
rm ~/miniconda3/miniconda.sh
```

### 3 安装 Python+PIP

推荐使用 Python3.11，至少 3.10 版本，便于后面 AI 环境的操作。

#### 3.1 安装 Python 3.11

打开终端，依次执行


```
# 更新Ubuntu
sudo apt update && sudo apt upgrade
# 导入包含最新稳定版本的 Python 存储库
sudo add-apt-repository ppa:deadsnakes/ppa -y
# 更新Ubuntu
sudo apt update
# 安装3.11
sudo apt install python3.11
# 查看是否成功
python3.11 --version
# 安装所有Python附加功能（可选）
sudo apt install python3.11-full
```

#### 3.2 安装 PIP

我们下载许多库和包，都需要用 PIP 下载，到手后，也必须安装的，打开终端：


```
# 直接安装
sudo apt install python3-pip
# 如果安装不成功，手动安装
# 手动下载
wget https://bootstrap.pypa.io/get-pip.py
# 手动安装
python3 get-pip.py
# 升级一下版本
python3 -m pip install --upgrade pip
# 查看是否安装成功
pip --version
```

搞定以上，我们开始搭建知识图谱环境。

## （二）部署 NebulaGraph

知识图谱是一种使用图结构的数据模型或拓扑来集成数据的知识库。三元组是知识图谱的基本数据单元，而 NebulaGraph 图数据库可通过存储三元组来高效地存储和查询复杂的图数据，从而实现知识图谱的搭建。

以下有三种 NebulaGraph 的部署方式，可根据实际情况进行选择。

|序号|应用场景及部署方式|系统平台|部署难度|性能评级|
| --- | --- | --- | --- | --- |
|1|学习-快速部署|多系统通用|★|★★★|
|2|实践-单机部署|Linux 系统|★★|★★★★|
|3|生产-集群部署|Linux 系统|★★★★★|★★★★★|

### 1. 学习-快速部署

docker 部署，主打快，0 代码部署，多平台支持，包含了 NebulaGraph 图数据库+ NebulaGraph Studio

下载地址⬇️

https://hub.docker.com/extensions/weygu/nebulagraph-dd-ext

本地点击 NebulaGraph Studio，即跳转到登录界面，填上本机 IP 即可登录，默认端口 9669，如未启用身份验证，填写默认用户名 root 和任意密码，如已启用，密码则为 nebula.

![](https://pic1.zhimg.com/80/v2-31d999e88e11522d696e94d21834a377_1440w.jpg?source=d16d100b)



### 2. 实践-单机部署

本系列教程推荐单机部署，同样条件下，有不错的性能同时，部署还相对简单。

#### 2.1 使用 tar.gz 文件安装 NebulaGraph

请参考 NebulaGraph 3.8.0 官方文档⬇️

https://docs.nebula-graph.com.cn/3.8.0/4.deployment-and-installation/2.compile-and-install-nebula-graph/4.install-nebula-graph-from-tar/

#### 2.2 使用 RPM 或 DEB 包安装 NebulaGraph

请参考 NebulaGraph 3.8.0 官方文档⬇️

https://docs.nebula-graph.com.cn/3.8.0/4.deployment-and-installation/2.compile-and-install-nebula-graph/2.install-nebula-graph-by-rpm-or-deb/

### 3. 生产-集群部署

#### 3.1 硬件要求

既然到了生产需求，不得不说硬件要求，我们要生产使用，所以必须要有一定硬件：

|类型|要求|
| --- | --- |
|CPU 架构|x86_64|
|CPU 核数|48|
|内存|256 GB|
|硬盘|2 * 1.6 TB，NVMe SSD|
|GPU|最低 3090 双卡（24G*2），两个 7B 左右模型一个做图谱，一个做 chat|

#### 3.2 存储硬件

NebulaGraph 是针对 NVMe SSD 进行设计和实现的，所有默认参数都是基于 SSD 设备进行调优，要求极高的 IOPS 和极低的 Latency.

* 不建议使用 HDD；因为其 IOPS 性能差，随机寻道延迟高。

* 不要使用远端存储设备（如 NAS 或 SAN），不要外接基于 HDFS 或者 Ceph 的虚拟硬盘。

* 不建议配置独立磁盘冗余阵列（RAID）。NebulaGraph 本身提供多副本机制，配置 RAID，会造成资源浪费

* 使用本地 SSD 设备；或 AWS Provisioned IOPS SSD 或等价云产品。

以上，仅仅是知识图谱能应用于生产的基本要求，如果你还需要结合大模型来做生产，那这个硬件配置还需要往上走，所以，目前大模型的推理成本比较高，如果你没有确切的需求，建议先用 API 来测试，统计 tokens 吞吐数据，再规划算力平台。

#### 3.3 使用 RPM/DEB 包部署 NebulaGraph 多机集群

请参考 NebulaGraph 3.8.0 官方文档⬇️

https://docs.nebula-graph.com.cn/3.8.0/4.deployment-and-installation/2.compile-and-install-nebula-graph/deploy-nebula-graph-cluster/

# 三、总结

本期「星云实验室」带领大家完成了 AI 环境的搭建和 NebulaGraph 的部署，下期我们将介绍如何在本地接入大模型和文本编码模型，并利用模型对现有文件生成知识图谱数据，并将知识图谱数据接入到 RAG 框架中提高回答准确性。

今天的“作业”完成了吗？欢迎在评论区“交作业”～

---

NebulaGraph 邀你参加开源之夏🌟⬇️

[开源之夏｜从 NebulaGraph 开启你的图数据库开源之旅！](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516493&idx=1&sn=cf0fac7165210fee057a889c77b6888b&scene=21#wechat_redirect)

手把手教大家围绕知识图谱+GraphRAG, 从 0 到 1 搭建一款垂直领域 AI 应用

星云实验室 part 1｜用知识图谱+GraphRAG,构建垂直领域 AI 应用

> 导读：「分布式锁」技术科普系列，由 NebulaGraph 存储负责人 @critical27 整理自己的“学习笔记”而成。在单体应用中我们通过锁实现共享资源访问，而在分布式系统中，则通过分布式锁解决。NebulaGraph 作为一款分布式图数据库，邀请大家一起学习分布式系统架构中的分布式锁～

重点速览：

* 为什么需要分布式锁？

* 分布式锁能够保证什么？

* 常见的分布式锁实现方式有哪些？

![](https://pic1.zhimg.com/80/v2-2625aa7ec640d0b58ff7c62b1203180c_1440w.jpg?source=d16d100b)



# 一、Distributed Lock

在单机多线程环境下，我们可以通过以下方式进行同步：

* 互斥锁 mutex

* 信号量 semaphore

* 用户态互斥锁 futex

那如果在分布式环境下，需要处理资源抢占问题时，我们经常想到的就是分布式锁和一致性共识协议。事实上，分布式锁就是一个简化版的共识协议，我们可以从一个分布式锁需要保证的几个性质来理解这一点：

1. Mutual exclusion: 同一个时刻只有一个客户端持有锁

2. Deadlock free: 不会因为出现死锁，进而导致有客户端始终无法获取到锁的情况

3. Fault tolerance: 一个分布式锁不能因为单点故障进而导致客户端始终无法获取到锁的情况

熟悉分布式系统的同学很快就能联想到，其实上面的三点本质上就是在描述两个重要性质：safety 和 liveness. 其中 safety 对应第一点，liveness 对应后两点。

**简单来说，safety 是系统的 invariant，无论何时系统都需要保证 invariant 成立。而 liveness 则是强调系统无论什么环境下，都要能最终保证其工作最终能够完成。**

举个例子，著名的哲学家进餐的解决方法和分布式锁需要保证的 safety 和 liveness 性质如出一辙：

* safety: 因为叉子不能共享，一个正在吃饭的哲学家两侧的哲学家不能在同时吃饭。

* liveness: 没有哲学家会挨饿，也就是有限时间内饿了的哲学家都能吃上饭。

> 其实用 TLA+ 来验证很多分布式算法时，验证的条件就是 safety 和 liveness. 我们后面会试着用 TLA+ 来描述一个分布式锁的实现。

如果一个分布式锁能够保证 safety 和 liveness，本质上就是一致性共识协议，也就是所有客户端通过分布式锁服务要能对当前谁持有锁达成共识。

**那为什么不直接用一致性共识协议呢？原因有以下几点：**

1. 一个完整的共识协议，比如 Paxos 和 Raft，其工程实现难度会比一个分布式锁服务复杂很多。又或者说，我们可以基于共识协议来实现分布式锁，比如著名的 ZooKeeper 和 etcd. 他们暴露了相对容易使用的分布式锁接口，但其内部仍然是是使用 Paxos 或者 Raft 来达成共识。

2. 上一点也提到，分布式锁的接口只关注于获取锁和释放锁，比一致性共识更加容易理解和使用。

3. 一个分布式锁服务可以独立部署，并供多个业务使用。

**分布式锁有几种常见的实现方式：**

* 基于数据库的实现：不管是不是内存型数据库，都是往数据库中写入一条携带 uuid 或者自增 id 的记录。通过检查这条记录中的 id 信息是否和客户端匹配，进而获知自己是否上锁成功。

* 借助分布式应用程序协调服务：比如前面提到的 ZooKeeper 或者 etcd，它们的客户端都提供了能够实现分布式锁的接口。

不同分布式协调服务的实现原理不尽相同，不在本文描述范围之内。本文重点还是关注基于数据库的实现，主要以 Redis 为例，整体思想大同小异。

> 选择 Redis 为例的一个重要原因是，关于 Redis 分布式锁在几年前有两个大牛也下场进行了一波争论。

# 二、基于单机数据库的实现方式

一种最简单的方式就是所有客户端，通过往数据库中写入一条记录表示获取锁，而删除掉这条记录就代表释放锁。当然获取锁的时候需要检查记录是否存在，比如通过 `IF NOT EXISTS` 这样的关键词。比如在 Redis 中就可以通过这样一条命令来完成，其中 `SETNX` 代表 `SET if Not eXists`.

```
SETNX lock 1 // 1是客户端id
```

1. 如果 Redis 中一开始没有 lock 这条记录，那么执行这条命令的客户端 1 就会成功写入 lock，代表获取锁成功。此时就可以去对分布式锁保护的共享资源进行相应操作。

2. 如果此时客户端 2 执行上锁逻辑就会返回失败，即获取锁失败。

3. 当客户端 1 进行完相应操作后，通过 `DEL lock` 删掉这条记录，代表释放锁。之后其他客户端就可以继续尝试写入 lock 获取锁。

## （一）如何避免锁不释放

**上面的方案非常直观，但有一个明显的问题，如果客户端上锁成功之后没有释放，此后其他客户端都无法获取锁，违背了 liveness 性质。**

没有释放的情况很多：

1. 应用程序忘了释放

2. 客户端进程出现了 stop-the-world 的 GC

3. 客户端进程挂掉了，节点宕机，机房断电等等

想要解决这个问题，一个通常的做法就是对这个数据增加一个过期时间 TTL(Time to Live)。当这个数据存活时间达到 TTL 之后，数据库就会自动将其删除，也就是锁自动释放。这个过期时间设置长短，需要考虑操作共享资源需要多长时间。比如在 Redis 中，我们可以对 lock 这条数据设置 10 秒的过期时间。

```
SETNX lock 1
EXPIRE lock 10
```

**那么 Redis 能否保证这两个命令能原子完成呢**？**答案是否定的**，也就会出现第一个命令成功，而第二个命令失败的情况，仍然会出现无法上锁成功的情况。 Redis 后来提供了原子的命令，保证两个操作能够原子执行。
```
// 下面的两个命令都等价于SETNX lock 1和EXPIRE lock 10
// 但能保证原子执行
SET lock 1 NX EX 10        // EX代表秒
SET lock 1 NX PX 10000     // PX代表毫秒
```


## （二）如何避免释放掉其他客户端上的锁

**增加了 TTL，就可能出现另一种问题**：客户端 1 操作共享资源期间，由于各种原因，时间超过了 TTL，此时 Redis 就会把客户端 1 上的锁释放。进而客户端 2 就会获取到锁，如果此时客户端 1 刚好操作完共享资源，开始释放锁，不就把客户端 2 的锁给释放了吗？

![](https://pica.zhimg.com/80/v2-8376e08737ed5caa570c24def32d3fd8_1440w.jpg?source=d16d100b)


**解决这个问题的关键就在于判断当前持有锁的客户端是不是自己**。回顾以下我们获取锁的命令是 `SET lock 1 NX EX 10`，其中 `1` 是客户端的 id. 之所以要把自身 id 写入到锁之中，就是为了在释放锁时检查持有锁的 id. 这是一个典型的 read-modify-write 操作，实际上就是要原子的执行如下伪代码：

```
If get(lock) == $id
    del(lock)
```

然而 Redis 没有提供这样原子执行的命令，而是通过调用 Lua 脚本的形式可以保证原子性。

```
if redis.call("GET", KEYS[1]) == ARGV[1]
then
    return redis.call("DEL", KEYS[1])
else
    return 0
end
```

如果 `get` 和 `del` 不是原子执行的，也会出现违反 safety 的现象。到这里，一个基于单机数据库的分布式锁服务基本就完成了。

然而，如果这个单机数据库发生了单点故障呢？这时候我们就只能将分布式锁服务替换成一个分布式服务了。

## （三）基于主从数据库的实现方式

如果我们基于主从数据库来实现一个分布式锁服务，最大的困难就在于主从复制是异步完成的。

**一种违背 safety 性质的情况如下：**

1. 客户端从主库获取锁成功

2. 主库在复制分布式锁这条记录之前 crash，此时从库中并没有相关记录

3. 从库被升为主库，此时其他客户端就可以获取锁。此时就会有两个客户端都以为已经成果获取锁，因此可能同时操作共享资源。

## （四）基于数据库 Quorum 的实现方式

主从数据库作为分布式锁服务的最大问题在于，客户端每次只和其中一个数据库节点进行通信，而主从数据库之间是异步复制，导致主库和从库之间有可能没有对哪个客户端获取成功锁达成共识，进而导致违背互斥。

想要解决这个问题，首先我们仍然需要多个数据库节点，但客户端在上锁时要么直接和多个数据库同时通信，并获取其中大多数的授权。要么多个数据库之间有一个一致性共识协议，客户端每次只和 leader 节点通信，由 leader 节点负责确保大多数节点达成了共识，并告知客户端上锁成功。后一种方法，其实已经和 ZooKeeper 和 Etcd 非常接近了。

# 三、Redlock

Redis 的作者后来基于 Qruorum 提出了 Redlock 这种分布式锁解决方案，这个方案有 2 个前提：

1. 多个 Redis 都是主库，不使用从库和哨兵实例

2. 主库要部署多个，官方推荐至少 5 个实例

**Redlock 的主要流程如下：**

1. 获取当前时间 `T1`，然后客户端依次对多个 Redis 实例进行加锁（方式和单个 Redis 上锁命令相同）。

2. 为了避免在某个节点长时间获取不到锁而阻塞，每次获取锁操作也有一个 timeout，并且远小于锁的过期时间 TTL. 如果对单个节点获取锁的时间超过 timeout 则认为失败，立即向下一个节点获取锁。

3. 当往所有节点都发送加锁命令后并取得结果(无论结果是成功、失败还是超时)，此时获取当前时间 `T2`，获取多把锁的总消耗时间就是 `T2 - T1`。只有在超过半数节点都上锁成功，并且 `T2 - T1 < TTL`，则认为成功获取锁。

4. 如果在第 3 步获取锁成功，需要重新计算当前锁的有效时间，避免在锁过期之后仍然操作共享资源。即分布式锁最早失效时间 `MIN_VALIDITY = 过期时间TTL - (T2 - T1)`。如果考虑时钟漂移，那么 `MIN_VALIDITY = 过期时间TTL - (T2 - T1) - 时钟漂移`。即在 `T2 - MIN_VALIDITY` 这段时间，客户端能够确保唯一持有分布式锁。当使用完共享资源后，也会向所有 Redis 实例发送释放锁的命令。

5. 如果在第 3 步获取锁失败，要向所有 Redis 实例发送释放锁的命令。

我们可以结合 Redlock 是如何保证 safety 和 liveness 性质来理解这个方案。

## （一）Safety Arguments

分几种情况来看：

* 如果客户端用大于等于 TTL 的时间来对所有 Redis 节点进行上锁，此时第 3 步会检查失败，并开始向所有节点释放锁。此时客户端并没有获取锁成功，可能有其他客户端获取锁成功，不违背 safety.

* 如果客户端用小于 TTL 的时间对所有 Redis 节点进行上锁，此时第 3 步会检查成功，认为该客户端获取分布式锁成功。**此时是如何保证 safety 成立呢？**

由于客户端至少向大多数的 Redis 节点成功写入了记录，因此成功写入的这些 Redis 节点保存的这条记录 TTL 相同（客户端上锁时指定的过期时间相同），而这些节点中这条记录的过期时间不尽相同（客户端往不同节点写入这条记录的时间不同）。

这里需要注意，客户端是从大多数 Redis 节点获取锁成功，有小部分 Redis 节点是可能超时或者获取锁失败的，我们也无需考虑。

在这些成功写入的节点中，最早写入成功的时间 `Tmin` 一定大于 `T1`（因为从 `T1` 之后才发送了请求），而最晚写入的时间 `Tmax` 一定小于`T2`（因为 `T2` 时刻已经获取到了所有节点加锁结果）。那么这个分布式锁最早失效的时间就是最早成功写入记录这个节点的失效时间（因为这个节点过期，可能就会导致不满足 Quorum）。

由于我们无法精确知道 `Tmin`，我们可以转而使用 `T1` 来进行如下推导：

```
  第一个写入成功的Redis节点这条记录的过期时间
= TTL + Tmin
> TTL + T1
> TTL - (T2 - T1)
> TTL - (T2 - T1) - CLOCK_DRIFT
= MIN_VALIDITY
```

由此得到分布式锁的最早失效时间 `MIN_VALIDITY = TTL - (T2 - T1) - CLOCK_DRIFT`。在 `[T2, MIN_VALIDITY]` 这段时间之内，大多数节点的这条记录都没有过期。**换句话说，其他客户端是不可能在这段时间之内往大多数节点写入这条记录，即不可能获取分布式锁。因此 Redlock 能够保证 safety.**

> 推导过程中要引入 T2 和时钟漂移的原因在于，客户端往所有节点写入记录的时间也需要记录在内。

## （二）Liveness Arguments

**Liveness 成立主要依赖以下三方面：**

1. Redis 会根据本地时间进行过期锁的清理

2. 客户端在获取锁失败或者获取成功并使用完资源后时，会往所有节点发送释放锁的命令

3. 当客户端获取锁失败之后，会等待一段时间然后再重试（常见的 back-off 重试，避免并发场景下多个客户端始终无法获取 Quorum）

由于有这几种清理和重试的机制，保证了多个 Redis 组成的分布式锁服务不会出现时钟无法获取分布式锁的情况。

不过 Redis 自己的官方文档中，描述了这样一种场景：如果每次客户端获取到分布式锁之后，在客户端向 Redis 发送释放锁的命令之前，客户端被网络隔离，在锁过期时间 TTL 之前，其他节点无法获取到分布式锁。如果网络时断时续这种情况一直出现，也就会导致整个分布式锁的可用性大大降低。

## （三 ）What if Redis crashed?

**如果 Redis 没有开启任何持久化，当节点 crash 时，Redlock 是否能满足 safety 呢？**

**答案是否定的**。

比如一个客户端在 ABCDE 这 5 个节点中的 ABCDE 上锁成功，成功获取了分布式锁。如果此时 A 进程 crash 并重启，那么其他客户端就可以从 ADE 获取到同一个分布式锁。

想要完全避免这个问题，**一种办法是每次 Redis 都需要把记录落盘**，即开启 `fsync=always`，性能肯定会大打折扣。

**另一种办法就是当 Redis 节点重启之后，只有经过一个 TTL 时间，才能对外服务**。这样也就避免了 A 重启之后再次上锁成功的问题（因为之前的锁一定已经过期）。这个办法的缺点在于如果节点频繁重启，也会大大影响可用性。

然而，当 Redlock 提出之后，DDIA 的作者 Martin Kleppman 就质疑了这个算法，后来 Redis 的作者 Antirez 也下场进行了反驳。两个人都是大牛，到底谁说的更有道理呢？我们下一期「分布式锁」技术科普再继续讨论～

---
**Reference**

[1]万字长文说透分布式锁：https://zhuanlan.zhihu.com/p/403282013

[2]Distributed Locks with Redis：https://redis.io/docs/latest/develop/use/patterns/distributed-locks

[3]Redis 实现分布式锁：https://juejin.cn/post/6975069367574888478

---

NebulaGraph 邀你参加开源之夏🌟⬇️

[开源之夏｜从 NebulaGraph 开启你的图数据库开源之旅！](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516493&idx=1&sn=cf0fac7165210fee057a889c77b6888b&scene=21#wechat_redirect)



为什么需要分布式锁？分布式锁能够保证什么？常见的分布式锁实现方式有哪些？

深入理解分布式锁的原理与实现

![](https://pica.zhimg.com/80/v2-f8069387e7bccd5da919bb214949cd45_1440w.jpg?source=d16d100b)


2025 年 5 月 15 日，NebulaGraph 迎来开源六周年的里程碑。作为国产开源图数据库的标杆项目，回望 NebulaGraph 的六年发展历程，不仅是一部技术迭代的编年史，更是中国开源社区在全球基础软件领域崛起的缩影。

# 一、诞生：在数据关系的浪潮中扬帆起航

> 2018 年 8 月 31 日， @Sherman-the-tank 在 nebula 仓库中提出第一个 issue ‘Create a parser framework to process GQL.’ 

> 2018 年 9 月 5 日， @dutor提交了第一个 PR ‘Added some concurrent utilities, GenericThreadPool, etc.’

NebulaGraph PMC Sherman Ye 曾参与多个分布式数据库研发工作，当社交网络爆发式增长，引发数据关系挖掘需求井喷时，他敏锐地意识到：图数据库是表示和理解关系最天然的工具，然而当时的图数据库或受限于单机性能，或困于扩展性不足，难以承载千亿节点、万亿边级的超大规模数据。

**“我们必须打造一款开源的、分布式的、支持线性扩容的世界级图数据库，能够容纳千亿顶点和万亿边。”Sherman 的愿景，从一开始就超越了代码本身。**

![](https://picx.zhimg.com/80/v2-cae41db3b74f9ccfb615a74d1c0edb31_1440w.jpg?source=d16d100b)

（NebulaGraph 诞生于一间小公寓 初期核心团队在这里办公）

NebulaGraph 采用 Shared-Nothing 架构与存储计算分离设计，为 NebulaGraph 注入了宇宙级的基因——每个节点独立处理数据，如同星云中的星辰，既自由又协调；存储与计算分离，则让扩容像星云膨胀般自然。

“**我们写下 NebulaGraph 第一行代码时，就认识到它必须是一款开源的图数据库**。”不忘开源初心，八个月后，NebulaGraph 遵循 Apache 2.0 开源协议，在 GitHub 开源 alpha 版本，从此开启了突破国产图数据库技术的星辰大海征程。

![](https://picx.zhimg.com/80/v2-6c5c52977d830ba58b030f87d07e5136_1440w.jpg?source=d16d100b)

（一张开源纪念截图）

# 二、应用：在产业实践的土壤中扎根

> 2024 年 10 月 29 日，携程云原生技术总监周昕毅先生在上海 nMeetup 上充分肯定了 NebulaGraph 作为开源解决方案在企业中的应用。

**用户的选择是最好的背书。六年来，NebulaGraph 用户覆盖金融、互联网、通信、电商、保险、安全等多个行业。**

![](https://picx.zhimg.com/80/v2-373380657d367374a5c236010ff40867_1440w.jpg?source=d16d100b)

（NebulaGraph 部分用户）

**携程集团已有包括酒店、机票、金融在内的 16 个部门使用 NebulaGraph, 在风控场景，构建了实时图特征平台的应用逻辑闭环，额外获取了 55% 的关联业务信息，使得该场景下的覆盖率提升了32% ；奇富科技打造了智能化的金融反欺诈系统系统，累计报送涉骗阻断预警 59 万次，拦截潜在被骗者 9.5 万人，帮助用户避免损失 11.35 亿元；OPPO 从 JanusGraph 切换到 NebulaGraph 后，导入性能提升了 10 倍，且查询性能以及并发能力都有 3-6 倍的提升。**

NebulaGraph 是开源项目，用户在真实使用场景中，为解决业务需求，会自然地参与共建，这种集体智慧加快了 NebulaGraph 的迭代：企查查贡献了 Node 客户端，奇富科技阿旺把自己做的 nebula-console-intellij-plugin 捐给了社区，笃笃科技大叶开发了 NebulaGraph 图数据库客户端星影 StarShadow.

一幅技术扎根产业、需求反哺产品的共生图景已然成形。这正是 NebulaGraph 在真实商业土壤中向下扎根、向上生长的最佳注脚。

# 三、生态：在开源共治的生态中繁荣

> 2024 年 3 月，NebulaGraph 在 GitHub star 数突破 10,000 大关

NebulaGraph 社区构建了一套自由且开放的“双轨成长体系”：开发者（Dev Group）聚焦代码贡献，用户（User Group）专注实践传播。细分来看，还有学习者、布道师、文档贡献者等角色，每种角色都能拥有自己的话语权，找到自己的存在价值，他们不会被统一地转化成某一类角色，他们被允许以某一种角色停留在社区里，比如仅仅作为用户，或者仅仅作为一次性的代码贡献者。

![](https://picx.zhimg.com/80/v2-43724d5cab1cdbeaee95c66d14d333f4_1440w.jpg?source=d16d100b)

（NebulaGraph Community 成长体系）

作为开源项目，我们始终重视代码共建共享。连续 5 年参与中国科学院软件研究所发起的开源之夏，鼓励全球高校开发者参与开源贡献，为社区注入新鲜血液；举办 NebulaGraph Hackthon，设立 150,000 奖金池，从内核到周边，让广大图数据库及 NebulaGraph 爱好者尽情探索图世界。

![](https://picx.zhimg.com/80/v2-ad23bf2576bb8365ee58049dc363f903_1440w.jpg?source=d16d100b)

（来自开发者的认可）

线下活动同样精彩纷呈。从 NUC 2021、2022，到足迹遍布全国的 nMeetup，我们珍惜每次与用户、开发者面对面交流的机会。也许大家素未谋面，但因为同在 NebulaGraph 社区，见证了万星开源项目的崛起，每次线下探索图数据库的世界都能像老朋友一样碰撞出思维的火花和久违的默契。

![](https://picx.zhimg.com/80/v2-acbd78d5d5eaeb7fea3b24b2fdf7f4ad_1440w.jpg?source=d16d100b)

（社区可爱的小伙伴们）

我们始终以包容的姿态，让每个社区参与者的独特贡献汇聚成生态繁荣的星河。

# 四、未来：在云与 AI 的浪潮中领航

## NebulaGraph Cloud

> 2020 年，NebulaGraph 决定打造云产品

**NebulaGraph 从诞生之初起，不仅坚定走开源路线，还坚持云原生理念**。

如今，NebulaGraph Cloud 作为一套集成了 NebulaGraph 数据库和数据服务的云上服务，支持一键部署 NebulaGraph 和相关可视化产品。用户可以在几分钟内创建一个图数据库，并快速扩展计算、存储等资源，无需在本地搭建和维护复杂的图数据库基础设施，从而能够更加专注于核心业务的发展。

![](https://picx.zhimg.com/80/v2-3679667464760cc091e5f9e580888f68_1440w.jpg?source=d16d100b)

（NebulaGraph 控制台界面）

NebulaGraph Cloud 除了在 AWS 上提供全托管服务，还计划全面支持 Azure 和 Google Cloud Platform (GCP) 等主流公有云厂商，企业可够根据自身需求和业务场景，选择最适合的云厂商。

申请试用⬇️

https://cloud.nebula-graph.io/login

## NebulaGraph AI 应用平台

> 2023 年 8 月 16 日，@wey-gu 与 LlamaIndex 联合发布 GraphRAG.

**正如 NebulaGraph 诞生之初，我们又一次站在高处看未来——洞察到图结构在知识处理中的革命性潜力。**

2023 年 8 月，在 RAG 技术还未被称为 RAG，而是上下文学习方法的时候，我们就意识到以图的方式处理知识会对解决“大海捞针”等特定问题有很大帮助，因此 @wey-gu 提出了将图数据库与 RAG 结合的想法，向 LlamaIndex 提了第一个 PR，将 KG-RAG 转变为 GraphRAG.

![](https://pica.zhimg.com/80/v2-755f74b891b440d4ab96e7c085d2d2e0_1440w.jpg?source=d16d100b)

（NebulaGraph GenAI Team Leader @wey-gu）

**GraphRAG 仅仅是 NebulaGraph 探索 GenAI 的“第一步”。**

随后，我们和 Researcher: Diego 一起讨论，做了图索引之上 Chain of Exploration 的工作，这种探索链不仅可以帮助 Agent 理解图谱，还能从非结构化数据中提取出半结构化的知识图谱‌。

在一系列 Graph based RAG 的落地实践中，GenAI Team 又一次突破技术边界，提出了 Fusion GraphRAG：融合了高级 RAG 技术，通过图状结构存储文档层级、章节关系及特殊元素（如公式、表格），实现高效、灵活的检索。

![](https://pica.zhimg.com/80/v2-53fcc2bde80b5e38c0d084167b7dee95_1440w.gif?source=d16d100b)

（Fusion GraphRAG 是更高级的 RAG 技术）

但不止于此，NebulaGraph 把视角转向企业级应用，基于 FusionGraphRAG 与 Agentic RAG 技术，打造了一个全新的高级知识库与低门槛应用平台 —— NebulaGraph AI 应用平台（内部命名为 “Catalyst”，即催化剂），无需构建复杂 Workflow 和编写繁琐 Prompt，更智能地激活与应用企业内部知识。

![](https://picx.zhimg.com/80/v2-30be65199160ee72e40dca63ec06000e_1440w.jpg?source=d16d100b)

（用户只需将对私有知识的理解转化为对不同“知识篮子”的定义）

从 GraphRAG 到 NebulaGraph AI 应用平台，**我们始终相信：真正的技术革命，不在于创造更复杂的工具，而在于让复杂技术变得触手可及。当每个企业都能像调配催化剂一样轻松激活知识资产，我们离智能时代的真正到来，便又近了一步。**

# 六周年快乐🎉

六载春秋，NebulaGraph 从一颗种子长成参天大树，其根系已深入全球开发者土壤，枝叶则伸向云与 AI 的星辰大海。NebulaGraph 的开源历程，证明了通过开源共治，我们能打造出一款世界一流的图数据库产品，更证明了这群活跃在开源社区的极客，有着无限的探索精神和创新能力。

因为开源，这场图数据库技术革命，没有终点，只有新的起点。

因为有你，这场开源协作的星辰征途，没有孤岛，只有携手同行的辽阔未来。


————————————分割线🎂————————————————

开源最大的意义，莫过于代码开放，共建共享，以用户/开发者的力量推动产品迭代。

陪伴 NebulaGraph 共同成长的你，是使 NebulaGraph 愈发闪耀的星光。

![](https://pic1.zhimg.com/80/v2-98225069fc5b2aad8690399a08f3607d_1440w.jpg?source=d16d100b)

[在 NebulaGraph 论坛，](https://discuss.nebula-graph.com.cn/t/topic/16781)分享你与 NebulaGraph 的故事，让更多小伙伴感受到开源的力量。

分享即送星云仔 T 恤，点赞 top3 可获得全套社区周边



‍

NebulaGraph 图数据库开源六周年：开源协作的星辰征途

> 导读：星影 StarShadow 是由 NebulaGraph Committer 大叶老师（CorvusYe@GitHub）开发的一款 ‌NebulaGraph 图数据库客户端，提供图数据库的可视化操作界面，让用户可以通过图形化的方式，对图数据库进行操作。自 2024 年 6 月发布以来，星影快速迭代，努力成为开发者们在图实践路上值得信赖的同伴。五一前，星影正式发布 2.0 版本，集成了 DeepSeek, 该 AI 模块命名"DeSrc". 今天，让 DeSrc 为 NGer 们规划一条「厦门三日游」路线，DeSrc 会有何推荐，又将给我们怎样的图数据库思考呢？

![](https://pica.zhimg.com/80/v2-09bb715bb2d2059481aa81deaca22f7f_1440w.jpg?source=d16d100b)


> 本文首发于[「NebulaGraph 技术社区」](https://mp.weixin.qq.com/s/hM8uOTWhgOp6nVJHBq4SdA)，更多资讯请访问[官网](https://www.nebula-graph.com.cn/)

# 一、起

在年初时，初步验证了DeepSeek 在构建知识图谱的可行性。

![](https://pic1.zhimg.com/80/v2-2db9395e2e52f8a902d336cb402cfdb9_1440w.jpg?source=d16d100b)

🔍[查看原文](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515229&idx=1&sn=8ca09cc8f23728d80c8107129a888801&scene=21&poc_token=HMQhI2ijSe7aRjeWOPkvcgXZLpxVbEcfT2klXt5Y)

经过数月的摸索与研发，最终在图数据库客户端星影中集成，并将完成之后的模块取名 DeSrc，大致流程如下：

![](https://pica.zhimg.com/80/v2-ff6d89b3c7c6cba4c9a6657ec6a02fb0_1440w.jpg?source=d16d100b)


# 二、承

今天，带来一个小案例，使用 DeSrc 规划一条厦门三日游路线，并将数据保存到 NebulaGraph 数据库中。

![](https://picx.zhimg.com/80/v2-1e665a71d118ad77c22d7af7ade84a37_1440w.gif?source=d16d100b)

（完整过程截图过长，请见文末）

小案例的输入输出过程如下：

* 输入： 帮我出一个厦门的旅游攻略图谱，需要有日程安排、公共交通方案等，需要涉及吃住行及用时，公共交通的线路。

* 输出：

![](https://picx.zhimg.com/80/v2-52908df37324565e2033daead36ed4d3_1440w.jpg?source=d16d100b)


> 以上推荐由 AI 生成，不代表文章观点，仅供参考。

从旅游的角度看，在三天的行程里，AI 推荐了 6 个景点、3 家具有当地特色的餐馆，6 个住宿区。总体来看算是比较经典的线路安排，偏简单。

从技术的角度看，看似简单的背后，也藏着点“猫腻”。在整个过程中，AI 完成了 4 个 Tag 及 6 个 EdgeType 的设计，并写入了 18 个节点及 20 条关系。

# 三、转

当然，从提出需求到生成图数据的过程中，并非一帆风顺。

在需求的描述中提到了“公共交通方案”，但图数据中并未体现这部分信息，因为 AI 在生成 nGQL 的过程中出现了语法错误，但为了顺利形成图数据，被我人为干预修正了，但在详细思考之后，个人认为这是个具有参考意义的错误，所以称之为“美丽的错误”。

以下截取几段这个“错误”的相关脚本：

```
INSERT VERTEX `ScenicSpot` (
  spotId, name, coordinates, visitDuration, ticketPrice
) VALUES
'Spot_GDY':(101, '鼓浪屿', '24.4489,118.0664', 180, 35),
'Spot_ZSL':(102, '中山路步行街', '24.4795,118.0894', 120, 0);

INSERT VERTEX `Transport` (
  transportId, vehicleType, routeNumber, duration, cost
) VALUES
'Transport_LY':(201, '轮渡', '邮轮中心厦鼓码头—三丘田码头', 20, 35);

INSERT EDGE `TRANSIT_CONNECT` (
  departure_time
) VALUES
'Spot_GDY'->'Spot_ZSL':'Transport_LY'@('16:00');
```

语法错误发生在脚本最后一行中，探究其意图，似乎 AI 想把一个实体锚定在一段关系中。而“两个地点的出发与到达”场景中，显然 AI 的想法虽然不符合语法，但却更为精准，如图：

> 为了方便表述与理解，我将代码中的鼓浪屿换成 A 地点,中山路步行街换成 B 地点，轮渡换成11路公交车。

![](https://picx.zhimg.com/80/v2-2fb8533155b3630a32b512f8f6377127_1440w.jpg?source=d16d100b)


而符合当前主流图数据库的存储方式又与场景相近的做法有：

1. 将摆渡方式作为一个中间节点，将三元组拆分成五元组

![](https://picx.zhimg.com/80/v2-ea21a5ce8bf179607a098927a1352b48_1440w.jpg?source=d16d100b)


这种修正方式的缺陷很明显，丢失了关系的同一性，或者说事件的同时性。

2. 将摆渡方式作为一个属性

![](https://picx.zhimg.com/80/v2-c3d62199d39124f09c0957d28ebc4c2a_1440w.jpg?source=d16d100b)


这种修正方式还有两种可能性：

* 实体名称当成边的一个属性

* 节点的 id 当成边的一个属性

无论上述哪种都依然带有难以消除的弊端：

第一点中，现实中实际存在的、有边界的、唯一的实体，以名称的方式参与到关系中，当多条关系出现同一名称，无法确定是否属于同一实物。

第二点中，以 id 作为属性虽然解决了同一性问题，但从当下主流图数据库查询返回值的角度，又很难将嵌入在边中的节点很好地表达出来。

# 四、合

那么问题究竟出在哪？

AI 的意图，本质上属于一种使用超图的解决方案。主流图数据库从存储到返回值，实现的都是一种普通图的方案。

> 在数学中，超图（Hypergraph）是一种广义上的图。不同于普通图的一条边只能连接两个顶点，超图的一条边可以连接任意数量的顶点。

按照超图的定义，AI 意图所形成的结构应为：

![](https://picx.zhimg.com/80/v2-635a390a055c17ad7aab72bf13332371_1440w.jpg?source=d16d100b)


而这种结构，在生活中更为常见。例如：五个人同时在一张桌子吃饭，用一条多端的边同时连接桌子与众人，对这一场景的表达最为精准。也许先前建模困难，时常需要在实际中纠结取舍，不能按生活直觉创建，或许原因就在于超图的模型要放入普通图的容器，难免有些水土不服，期待早日可以看到图数据库能具备超图的特性，或者如果已经有了，请带带我。

# 附：

1. 小案例过程 DeSrc 界面截图

![](https://pica.zhimg.com/80/v2-017dcb2cacf105967117d70e87702b04_1440w.jpg?source=d16d100b)

> 所用大模型为【阿里云百炼 DeepSeek-R1】

2. 数据可视化

图数据

![](https://pica.zhimg.com/80/v2-71380d5905d46798309b768c89300900_1440w.jpg?source=d16d100b)

路径数据

![](https://pic1.zhimg.com/80/v2-d4b988284a113ed6bc4767eded936681_1440w.jpg?source=d16d100b)

上图的行程大概就是，早上到鼓浪屿转一圈，在下午 16:00 前上轮渡出鼓浪屿，然后到对面中山路步行街喝点花生汤，再找找特色小吃，就可以结束 AI 推荐下的、朴素而又美好的一天。


**关于星影：**

🌟以上界面截图来自【星影 · 图数据库客户端】

🌟下载地址：https://dudu.ltd/

🌟点击「阅读原文」，了解更多星影 2.0 功能介绍

---

NebulaGraph 邀你参加开源之夏🌟⬇️

[开源之夏｜从 NebulaGraph 开启你的图数据库开源之旅！](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516493&idx=1&sn=cf0fac7165210fee057a889c77b6888b&scene=21#wechat_redirect)

用星影 StarShadow 2.0 规划一条「厦门三日游」路线

AI 生成旅游图谱：一次“美丽错误”的技术思考

> **导读**：NebulaGraph Cloud ‌是一个基于云上超大规模图数据库的解决方案，旨在简化数据库部署、性能调优和运维等繁杂过程，不仅几分钟内即可在云上创建一个图数据库，同时集成了多款可视化图数据库管理工具，给你带来更加便捷的一站式云端体验。秋招在即，一起来用 DeepSeek+ NebulaGraph Cloud 构建专属求职能力地图，祝大家都能拿到超棒的 offer！

![](https://picx.zhimg.com/80/v2-71423b995da177bc61e6da879ab84586_1440w.jpg?source=d16d100b)

# 一、背景

最近，星云仔邀请列表的高校开发者参与[开源之夏](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516493&idx=1&sn=cf0fac7165210fee057a889c77b6888b&scene=21#wechat_redirect)（🔍戳蓝色字体查看 NebulaGraph 项目详情），有许多小伙伴表示忙于准备秋招。其实“图”无处不在，在求职中也能发挥独特作用～今天，教大家用 Deepseek+ NebulaGraph, 轻松构建求职能力地图，希望能给大家一点启发。

我们用图谱形式可视化地更新和展示个人能力，既可以帮助我们定期复盘，拥有清晰的自我认知和定位。此外，通过求职能力地图，可精准匹配与自己能力符合的岗位，提高简历投递效率，告别盲目海投。

# 二、搭建步骤

## （一）构建图

![](https://pic1.zhimg.com/80/v2-3c7cdd8f48395b56b604bcaa7f8413c1_1440w.gif?source=d16d100b)


**Step 1 ：使用 DeepSeek 建模**

> 在 AI 涌现的时代，有哪些能力可以在竞争中获得成功，请用 NebulaGraph 的点边关系构建起求职能力地图。用表格形式整理核心能力和子能力以及对应关系。

得到下表：

![](https://pic1.zhimg.com/80/v2-4e17bd74a0d83a9d85896117814593ed_1440w.jpg?source=d16d100b)


**Step 2 ：使用 NebulaGraph Cloud 构建 Graph**

NebulaGraph Cloud 目前可免费试用，申请地址⬇️

https://cloud.nebula-graph.io/login

在 NebulaGraph Cloud 的 Graph 页面输入 DeepSeek 的结果构建五边形求职能力地图 (Graph)。

![](https://picx.zhimg.com/80/v2-730cf56301626462a74f8bc885c4a3ec_1440w.jpg?source=d16d100b)

## （二）导入数据

![](https://pic1.zhimg.com/80/v2-4865c59e02cf43a9ab972426777b32ab_1440w.gif?source=d16d100b)


**Step 1 ：使用 DeepSeek 提取简历**

> 根据我上传的个人简历，总结我具备的能力，并根据为每个能力的熟练程度打分，返回表格结果。

根据简历内容与核心能力模型匹配分析并生成能力评估表：

![](https://pica.zhimg.com/80/v2-c964bf8a92921c23da6d88fbb863a4f7_1440w.jpg?source=d16d100b)


**Step 2 ：使用 NebulaGraph Cloud 导入数据**

在 NebulaGraph Cloud 的 Import 页面导入 DeepSeek 总结的数据至已建立的求职能力地图模型 (Graph) 中。

![](https://picx.zhimg.com/80/v2-3ec007902b92ac48e98ef474672dd95d_1440w.gif?source=d16d100b)

## （三）探索数据

![](https://pica.zhimg.com/80/v2-a16f38b8dca67b839b6558883fe12593_1440w.gif?source=d16d100b)


在 NebulaGraph Cloud 的 Query 页面探索数据，获得求职洞察。

使用 GQL 语句，可以把 skills3 替换成你自己的 Graph 名称。

`USE skills3 MATCH (v) RETURN v`

搜索全局能力地图中所有的个人技能点，了解个人技能的分布状况。

![](https://pica.zhimg.com/80/v2-e06fec4b5147059a774f912e037f89d8_1440w.jpg?source=d16d100b)

每个能力的颜色代表着五边形能力地图的一个大类，从图中可以看到每个技能点，在每一方面都“雨露均沾”，颜色和数量的分布是非常均匀的，这代表求职者在 AI 时代，具备较强的核心竞争力。

# 三、总结

本文展示了与AI（Deep Seek R1 大模型）对话与在 NebulaGraph Cloud 操作的大致过程，结果仅用于启发思路，你也可以结合这些工具探索其它使用场景，比如生成一个数据库内核研发工程师的核心竞争力图，作为面试“风向标”。

期待大家大家在 NebulaGraph Cloud 上的更多探索，并来论坛分享～有参考价值的 case 将会收到星云仔限定 T 恤和徽章喔～

![](https://pic1.zhimg.com/80/v2-56ddfb3d7b99f794ca7d86409049aa70_1440w.jpg?source=d16d100b)


秋招在即，一起来用 DeepSeek+ NebulaGraph Cloud 构建专属求职能力地图

用 DeepSeek+ NebulaGraph Cloud 构建专属求职能力地图

> ​
导读：在数据库的运维实践中，集群迁移与版本升级是及时满足业务需求的关键环节。这篇经验贴分享了使用 NebulaGraph Spark Connector 将多个业务的集群从 NebulaGraph 2.6.2 向 3.8.0 版本迁移，并部署到各自对应新集群中的完整方案，涉及业务隔离集群搭建、跨版本数据转运、脏数据处理等核心要点。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/425/%E5%A5%87%E5%AF%8C%E7%A7%91%E6%8A%80-7.png)


# 一、背景


* 多个业务使用同一套 NebulaGraph 集群,当其中某一个业务有大量耗时查询或者大量数据加载时,这时此集群的压力可能会急剧上升,导致所有的业务出现服务性能极度下降的情况；

* NebulaGraph 使用古早的 2.6.2 版本，很多业务需求较难快速实现。


# 二、需求

* 为每个业务搭建一套属于自己的 NebulaGraph 集群;
* 将旧集群中的各个业务的数据迁移到自己业务对应的新集群中;
* 新集群需要使用 3.8.0 版本 NebulaGraph;
* 旧的 NebulaGraph 集群下线。


# 三、数据迁移工具选型

通过 NebulaGraph 官网查看有没有现成的数据迁移工具，能直接实现我们的需求，调研如下：

* 社区版的 NebulaGraph BR：限制是版本为 3.x 才能用；只能恢复到原集群，不可跨集群等等。遂放弃。
* NebulaGraph Importer：导入数据使用。这个之前没怎么用过，应该是使用官方提供的工具执行相应的命令将数据发送到对应的集群。考虑到失败无法重试的缘故，遂放弃。
* NebulaGraph Exchange：这个主要考虑到配置文件的繁琐性，且我们集群上的 Spark 客户端一般不暴露出来直接使用，都是通过 dolphinscheduler 使用的。遂放弃。
* NebulaGraph Spark Connector：连接器使用，通过官网的 demo 发现这个可以将 NebulaGraph 数据写成 DF 格式，还可以将 DF 格式数据写入 NebulaGraph；且通过 dolphinscheduler 好控制。因此，我们决定使用 NebulaGraph Spark Connector 进行数据迁移。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/425/640%20(3).webp)


# 四、具体步骤


## （一）NebulaGraph to HDFS

运行 NebulaGraph to HDFS 对应的工作流，将 NebulaGraph 数据备份到 HDFS。

edge 类型导入 HDFS 为例：


```
package nebula

import com.vesoft.nebula.connector.connector.{NebulaDataFrameReader, NebulaDataFrameWriter}

import com.vesoft.nebula.connector.{NebulaConnectionConfig, ReadNebulaConfig}

import org.apache.spark.sql.SparkSession

object Edge2HDFS {

  def main(args: Array[String]): Unit = {

    try {

      if (args.length < 4) {

        println("Usage: <space> <edge> <graph_host> <hdfs path>")

        System.exit(-1)

      }

      val space = args(0)

      val edge = args(1)

      val graph_host = args(2)

      val hdfsPath = args(3)

      val spark:SparkSession =SparkSession.builder()

        .appName(space + "_" + edge)

        .getOrCreate()

      val config = NebulaConnectionConfig

        .builder()

        .withMetaAddress(graph_host)

        .withConenctionRetry(2)

        .withExecuteRetry(2)

        .withTimeout(36000000)

        .build()

      val edge_config = ReadNebulaConfig

        .builder()

        .withSpace(space)

        .withLabel(edge)

        .withNoColumn(false)

        .withPartitionNum(400)

        .build()

      val edges = spark.read.nebula(config, edge_config).loadEdgesToDF()

      edges.repartition(400).write.

        format("json").

        mode("overwrite").save(hdfsPath)

    } catch {

      case e: Exception => {

        // 在这里捕获异常，并进行相应的处理

        // 例如，记录异常信息、进行异常恢复操作等

        e.printStackTrace() // 这里只是简单地打印异常信息，你可以根据需要进行适当的处理

      }

    }

}

}
```



## （二）HDFS to NebulaGraph

运行 HDFS to NebulaGraph, 对应的工作流把备份在 HDFS 上的数据加载到 3.8.0 的 NebulaGraph.

edge 类型导入 NebulaGraph 为例：


```
package com.nebula

import com.vesoft.nebula.connector.connector.NebulaDataFrameWriter

import com.vesoft.nebula.connector.{NebulaConnectionConfig, WriteNebulaEdgeConfig}

import org.apache.spark.sql.SparkSession

object Edge2nebula {

  def main(args: Array[String]): Unit = {

    try {

      if (args.length < 5) {

        println("Usage: <space> <edge> <graph_host> <hdfsPath> <meta_host>")

        System.exit(-1)

      }

      val space = args(0)

      val edge = args(1)

      val graph_host = args(2)

      val hdfsPath = args(3)

      val meta_host = args(4)

      val _SPARK_SESSION: SparkSession = SparkSession.builder()

        .appName(edge)

        .getOrCreate()

      val config = NebulaConnectionConfig

        .builder()

        .withMetaAddress(meta_host)

        .withGraphAddress(graph_host)

        .withConenctionRetry(2)

        .withTimeout(36000000)

        .build()

      // HDFS 目录路径

      val edgeHdfsPath = s"hdfs://HACluster" + hdfsPath + "/*.json"

      var edgeDF = _SPARK_SESSION.read

        .format("json")

        .load(edgeHdfsPath)

      edgeDF = edgeDF.withColumnRenamed("_srcId", "_vertexId")

      edgeDF = edgeDF.withColumnRenamed("_dstId", "dstId")

      edgeDF = edgeDF.withColumnRenamed("_rank", "rank")

      edgeDF.show(10)

      val edgeCount = edgeDF.count()

      // 打印记录总数

      println(s"Total number of rows: $edgeCount")

      val nebulaWriteContainConfig: WriteNebulaEdgeConfig = WriteNebulaEdgeConfig

        .builder()

        .withSpace(space)

        .withEdge(edge)

        .withSrcIdField("_vertexId")

        .withSrcPolicy(null)

        .withDstIdField("dstId")

        .withDstPolicy(null)

        .withRankField("rank")

        .withUser("root")

        .withPasswd("nebula")

        .withBatch(50)

        .build()

      edgeDF.write.nebula(config, nebulaWriteContainConfig).writeEdges()

    } catch {

      case e: Exception => {

        // 在这里捕获异常，并进行相应的处理

        // 例如，记录异常信息、进行异常恢复操作等

        e.printStackTrace() // 这里只是简单地打印异常信息，你可以根据需要进行适当的处理

      }

   }

}

}
```

将代码写好编译成 jar 包上传到 dolphinscheduler 并通过 dolphinscheduler 创建对应的工作流就可以用了。

贴一下 Spark 参数：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/425/640%20(4).webp)

## （三）数据量与准确性检验

数据量检验可通过执行 `SHOW STATS` 命令，对比新旧集群的统计信息，确保数据完整无缺失。准确性验证则通过在新旧 NebulaGraph 集群上执行相同的 nGQL 查询语句，对比返回结果是否一致。通过这两种方式，全面验证数据迁移的完整性和准确性，确保业务在新集群上可正常运行。


## 五、遇到的问题

1.读写时可能会遇到

`com.vesoft.nebula.client.graph.exception.IOErrorException: java.net.SocketTimeoutException: Read timed out`

这是我们设置的超时时间太短了。我们把withTimeout(36000000)设置得大一些就好了。

2.导入数据时可能会遇到

`RaftPart buffer is full`

这是我们并发设置得太大了，调整 Spark 参数，降低 Executor 数量，batch 数量等，减小并发。



3.如果遇到 NebulaGraph 中创建 tag 和 edge 使用的属性类型和数据类型不一致的脏数据的话，就无法正常读取数据到 HDFS.

这时候需要下载官网的 nebula-spark-connector 源码调整相应的部分，编译打包上传到自己的 maven 库引用，然后将脏数据找到，进行手动处理，再重新跑一遍 NebulaGraph to HDFS 对应的工作流。


# 六、总结

通过以上步骤，可使用 NebulaGraph Spark Connector 顺利实现复杂业务隔离需求下的 NebulaGraph 集群迁移与版本升级。NebulaGraph Spark Connector 是一个强大的生态工具，能够将 NebulaGraph 中的数据读取为 DF 格式，并支持将 DF 数据写入 NebulaGraph, 具有良好的扩展性和易用性，非常适合大规模数据迁移任务。希望本文能为其他有类似需求的社区用户提供参考与帮助。

可参考官方文档，进一步了解 NebulaGraph Spark Connector：

https://docs.nebula-graph.com.cn/3.6.0/connector/nebula-spark-connector/



​

篇经验贴分享了使用 NebulaGraph Spark Connector 将多个业务的集群从 NebulaGraph 2.6.2 向 3.8.0 版本迁移，并部署到各自对应新集群中的完整方案，涉及业务隔离集群搭建、跨版本数据转运、脏数据处理等核心要点。

复杂业务隔离需求下的 NebulaGraph 集群迁移与版本升级全攻略

在即将来临的暑假，尽情探索图数据库的新世界吧！2025 年开源之夏，NebulaGraph 社区发布了 4 个项目，更适合高校开发者的度假方式来啦～
![](https://pic1.zhimg.com/80/v2-6246d3cd5be02a458f713a84bf247cb5_1440w.png)


参与开源社区的代码贡献，和世界各地的开发者一起成长，这经历可超有含金量，可媲美大厂实习经历！

**2023 开源之夏参与者**

**NebulaGraph contributor 宋同学：**

> “参与 NebulaGraph 开源项目经历是我校招的加分利器，它让我积累了丰富代码经验，熟悉实战开发流程。还能学到课本外的前沿知识、热门技术框架。同时，许多大厂面试官都热衷贡献开源项目，这种共同爱好让面试更像朋友之间的技术交流。最终，我在秋招中顺利斩获了滴滴、小米、京东、快手等多个大厂 offer.”

![](https://pica.zhimg.com/80/v2-852c8f8bf6542ab54b7407d6dbe34628_1440w.png)

（图源宋同学在 nMeetup 上的分享）

# 开源之夏

开源之夏是中国科学院软件研究所于 2020 年发起的“开源软件供应链点亮计划”系列暑期活动，旨在鼓励高校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。

活动联合各大开源社区，针对重要开源软件的开发与维护提供项目开发任务，并向全球高校学生（需年满 18 周岁）开放报名。学生可自主选择感兴趣的项目进行申请，中选后在项目开发者（社区导师）的指导下进行开发。根据项目的难易程度和完成情况，结项者将获取开源之夏劳务报酬和结项证书。

💰**基础项目**：8000

💰**进阶项目**：12000

# NebulaGraph

NebulaGraph 是一个可靠的分布式、线性扩容、性能高效的图数据库，擅长处理千亿节点万亿条边的超大数据集，同时保持毫秒级查询延时的图数据库解决方案。

2019 年 5 月 15 日，NebulaGraph 在 GitHub 开源 alpha 版本，拥有遍布全球的用户和开发者以及活跃的社区，GitHub star 数超 11k.

作为开源项目，NebulaGraph 始终重视代码共建共享和高校开发者的培养，连续 5 年参与中国科学院软件研究所发起的开源之夏，鼓励全球高校开发者参与开源贡献，为社区注入新鲜血液。

# 为什么选择开源之夏 x NebulaGraph 项目？

* 代码能力跃升：你的代码将运行在支撑超大规模数据集群的图数据库中。

* 实习直通车：顺利结项并经导师推荐，将拥有 NebulaGraph 实习机会。

* 与大牛同行：4 位顶级导师带你玩转世界级分布式图数据库。

* 简历镀金：参与 GitHub 万星项目，开源贡献记录永久可见。

* 硬核成长：从内核到生态工具，贡献真实应用场景。

# NebulaGraph 项目介绍

## 01 NebulaGraph 支持向量近似近邻检索

* 项目难度：进阶

* 编程语言：C++

* 技能要求：

1. 熟悉 C++，对分布式数据库有一定开发经验。

2. 掌握向量检索的基本原理和算法，如 HNSW、IVF、Annoy 等。

* 项目描述：LLM 的创新推动了很多 AI 应用的落地，构建此类应用通常采用 RAG(Retrieval-Augmented Generation) 架构模式，RAG 被认为是解决 LLM AI 幻觉的有效方式，并可以为其提供更丰富的上下文使得 LLM 的响应更准确。向量近似近邻检索，即 Approximate Nearest Neighbor (ANN) Search，可以在高维向量空间中快速检索相似向量并为 RAG 提供后端支持。然而，目前 NebulaGraph 尚未支持向量相关的功能，这限制了其在 AI 场景中的应用潜力。若在 NebulaGraph 中支持向量，将为其提供向量持久化存储能力、利用数据库的扩展性来满足业务数据规模扩张需求、实现知识图谱和向量检索结合的 GraphRAG 来改善传统 RAG 的一些痛点。

* 项目产出：

1. 实现向量数据类型并支持其持久化。

2. 实现向量相关的 DDL 语句，包括 create tag、create index 等语句。

3. 实现向量相关的 DML 语句，包括 insert、update、delete 等语句。

4. 设计并实现 ANN Search 语句。

5. 满足分布式一致性和可用性要求，保证向量数据副本一致性及内存磁盘数据一致性。

* 导师：志鹏，NebulaGraph Committer.是一位开发经验丰富的图数据库内核研发工程师。在开源之夏，他以硬核的图数据库内核研发功底备受认可。志鹏的指导风格耐心细致，同时对新技术充满热情。

* 邮箱：kyle.cao@vesoft.com

## 02 NebulaGraph 集成 PyG

* 项目难度：基础

* 编程语言：Python

* 技能要求：需要熟悉 PyG 的 remote server 机制和 FeatureStore 与 GraphStore 抽象，并了解 NebulaGraph 的 基本知识，利用 NebulaGraph 的 GraphClient 和 StorageClient，实现 PyG FeatureStore 与 GraphStore.

* 项目描述：PyG 是一个用于在 PyTorch 中创建和训练图神经网络的强大而灵活的框架。它简化了图数据的处理，并提供了各种 GNN 模型的构建块，助力研究人员和开发者在图结构数据上进行创新。NebulaGraph 是一款开源的、分布式的、易扩展的原生图数据库，能够承载包含数千亿个点和数万亿条边的超大规模数据集，并且提供毫秒级查询。PyG 作为 GNN 的训练推理框架、它的图抽象支持从远程的分布式基础设施上存取，这个抽象叫“remote server”，有了这个抽象，我们可以连接两个项目，让 PyG 社区受益于 NebulaGraph 的超大规模分布式图存储，驱动分布式图申请网络的训练。

* 项目产出：设计实现 PyG 的 NebulaGraph remote server ，作为其 FeatureStore 与 GraphStore.

* 导师：思为，NebulaGraph Committer, NebulaGraph GenAI Team Leader. 作为 GraphRAG 的提出者，思为拥有无限想象力，指导风格充满激情与活力，善于引导你突破常规思维，大胆尝试新的技术方案。在他的团队里，每一个创意都能得到充分的尊重与支持。

* 邮箱：[wey.gu](http://wey.gu/)@vesoft.com

## 03 为 NebulaGraph 支持 Airbyte

* 项目难度：基础

* 编程语言：Java

* 技能要求：

1. 对 Airbyte 框架有一定的了解，有丰富的 Java 开发经验，对反射有充足的实践经验和认知。

2. 对数据的 ETL 过程有一定的了解。

* 项目描述：Airbyte 是一款领先的数据集成平台，专注于构建和管理 ETL（提取、转换、加载） 或 ELT（提取、加载、转换） 数据管道，帮助用户将来自多种源头（如 API、数据库、文件等）的数据高效迁移到现代数据存储与分析平台，包括 数据仓库、数据湖以及新兴的 数据湖仓等。期望在 NebulaGraph 上增加对 Airbyte 的支持，方便用户可以通过 Airbyte 将各种数据源的数据，导入到 NebulaGraph 中。

* 项目产出：

1. 增加 Airbyte 的 Writer，支持数据通过 Airbyte 从 Mysql 到 Nebulagraph 的迁移

2. 代码能够合入到 Airbyte 仓库，满足相关开发测试规范

* 导师：秋梵，NebulaGraph Contributor, 开源之夏 2024 年 NebulaGraph 项目导师，带领晓阳同学顺利结项，并获得 2024 年开源之夏“最快进步奖”。不仅热爱开源，秋梵还是一枚二次元爱好者，是能一起写代码也能一起追番的“中国好导师”。

* 邮箱：knqiufan@foxmail.com

## 04 为 NebulaGraph Exchange 支持数据源插件化

* 项目难度：基础

* 编程语言：Java、Scala

* 技能要求：

1. 对 Spark 分布式框架有一定的了解，有丰富的 Java 或 Scala 开发经验，对反射有充足的实践经验和认知。

2. 熟悉当前 NebulaGraph Exchange 项目的架构流程，了解 NebulaGraph Exchange 中的配置管理模块和数据源管理模块的逻辑流程。

* 项目描述：NebulaGraph Exchange 是一款专业的数据导入工具，致力于将各类异构数据源的高效导入到 NebulaGraph 图数据库中。当前版本已支持包括关系型数据库、NoSQL、大数据平台等在内的十余种主流数据源。但 NebulaGraph Exchange 的数据源都是内嵌在 NebulaGraph Exchange 的核心代码中，每添加一种新数据源都需要进行代码扩展和代码修改，然后进行重新打包发版，存在数据源与核心代码高度内聚的问题，使得添加新数据源和维护已有数据源的成本增加。基于以上背景，该项目旨在实现 NebulaGraph Exchange 数据源的插件化架构，通过标准接口和扩展机制，使 NebulaGraph Exchange 能够在无需修改核心代码的情况下，通过引入插件 JAR 包的方式灵活支持新的数据源。

* 项目产出：

1. 对当前 NebulaGraph Exchange 架构进行优化改进，将数据源相关的功能流程抽象化，实现数据导入和数据源管理的低耦合结构。

2. 实现不同数据源的插件化模块化开发，利用反射实现 NebulaGraph Exchange 对不同数据源插件 jar 包的动态加载和调用，从而实现各个数据源的独立化维护，增强 NebulaGraph Exchange 的数据源支持的能力，实现 NebulaGraph Exchange 数据源的插件化开发和维护，为用户自定义特殊的数据源提供抽象能力。

* 导师：昌圆，NebulaGraph Java 系列生态工具（NebulaGraph Exchange、NebulaGraph Flink Connector 等） Maintainer, 常被社区小伙伴称赞为“顶级大佬”。此外，昌圆发表了多篇图数据库相关专利，学术能力也一级棒，真·全能型导师。

* 邮箱：anqi.wang@vesoft.com

## 开源之夏活动流程

![](https://pic1.zhimg.com/80/v2-e9955e2ad3718ef1a734a605b5b9788c_1440w.png)


# To Do List

如果你对 NebulaGraph 发布的项目感兴趣，在接下来的一个月内，你需要做的事：

* 进入开源之夏官网，了解开源之夏每个流程的时间，并查看 NebulaGraph 项目详情；

* 访问 NebulaGraph 官网，查看 NebulaGraph 文档，进一步了解我们；

* 填写项目意向问卷，与 NebulaGraph 官方近距离交流项目详情⬇️；

* 根据开源之夏规定时间，完善个人信息并填写项目申请；

* 等待中选结果。

![](https://picx.zhimg.com/80/v2-a2256b10e92661a087125ed9c570a275_1440w.gif)



祝大家在开源世界里，收获满满～

度过一个有意义的暑假：）

开源之夏 2025 NebulaGraph 项目介绍

开源之夏｜从 NebulaGraph 开启你的图数据库开源之旅！

> 导读：作者黄春晖，震坤行大数据平台高级开发工程师，专注于工业 MRO 领域数据中台架构设计，2024 年开始推动 NebulaGraph 在公司多业务场景的深度集成，包括智能采购决策，供应链风控体系等。本文从业务痛点、NebulaGraph 选型与架构、业务场景、未来规划等方面，介绍 NebulaGraph 在震坤行的应用实践。

![](https://picx.zhimg.com/80/v2-21b824ac4d5404fe8612a05215408263_1440w.jpg?source=d16d100b)

# 一、业务痛点

震坤行工业超市是一家专注于数字化转型的线上工业用品服务平台，致力于为客户提供透明、高效、低成本的一站式工业品解决方案。

![](https://pic1.zhimg.com/80/v2-e5f606381161880efafda61c669ea9fb_1440w.jpg?source=d16d100b)

我们通过数字化管理工具和大数据技术，协同合作伙伴优化供应链全链路，覆盖从采购、制造到交付的全流程。同时，震坤行提供优质的工业品选购服务，结合自建仓储物流体系，为线上线下客户打造高效、可靠的工业品采购与交付体验。

![](https://picx.zhimg.com/80/v2-395711080c894bac9cd05999e52ae4ea_1440w.jpg?source=d16d100b)


我们在引入 NebulaGraph之前，业务痛点主要是以下三个方面：

* **数据规模与复杂性的双重压力**：业务扩展导致客户-供应商关系、客户行为等复杂关系数据快速增长，传统数据库难以高效存储和查询，实时分析需求难以满足。

* **关系数据库的局限性**：关系数据库在多表连接等操作上性能瓶颈显著，无法支持复杂关系数据的实时分析和深度挖掘，影响供应链优化等高价值场景落地。

* **数据价值落地困难**：复杂关系数据在供应链优化、风险预警等场景中的应用，面临数据建模、算法优化和效果验证等挑战，技术与业务深度融合是关键。

# 二、NebulaGraph 选型与架构

## （一）Why NebulaGraph？

* **高效的关系表达**：通过图结构直观表示实体及其关系，节点表示实体（如客户、供应商、商品），边表示关系（如供应、购买）。特别适合震坤行复杂的供应链网络，能清晰呈现多层次的客户-商品-供应商关系。

* **强大的路径分析能力**：支持高效的图遍历算法，能够快速进行路径分析（如最短路径、共同邻居等），为震坤行提供强大工具，用于挖掘客户需求、优化供应链路径和识别客户风险。

* **实时查询与响应**：具备高并发、低延迟的查询能力，支持实时推荐、风险预警等场景，满足震坤行对实时性的需求，助力用户行为分析和供应链动态调整，快速响应业务变化。

* **可扩展性与高性能**：采用分布式和存算分离的架构，支持水平扩展，轻松应对震坤行数据量的快速增长，确保高并发场景下依然保持高性能。

## （二）技术架构

![](https://pic1.zhimg.com/80/v2-302e108521f4cbfb16e9b4e19880608a_1440w.jpg?source=d16d100b)

1.**数据采集**

* 业务数据：来源于 ERP、MySQL、SQL Server 等系统，通过 DataX 或 Flink-CDC 工具同步到阿里云 MaxCompute.

* 埋点数据：通过 SDK 采集客户行为数据（如浏览路径、订单流程）并上传至阿里云 DataHub.

* 非结构化数据：包括合同、图片、文档等，通过 OSS 进行存储。

2.**数据加工**

数据采集完毕后，我们会采用以下两种方式进行计算。

* 离线计算：利用 MaxCompute 和 Spark 处理大规模批量数据，适用于数据清洗、聚合等任务。

* 实时计算：通过 Flink 处理流式数据，支持实时分析和响应。

3.**数据存储-NebulaGraph**

目前我们部署了两套 NebulaGraph 集群：

* 在线服务集群：面向实时查询结果，主要用于客户行为路径分析、客户关系查询等场景。

* 图算法集群：处理复杂图算法，支持供应商风险评估等高级分析。

4.**数据服务**

* API 网关：提供统一接口，支持应用鉴权、负载均衡和流量控制，确保服务的稳定性和安全性。

* 个性化 API：根据不同平台的不同业务需求提供定制化接口，例如客户行为路径分析、客户关系查询、供应商风险评估。

# 三、应用实践

## （一）应用场景之精准推荐

![](https://picx.zhimg.com/80/v2-1fd42e4f209aff3e6c11b90add12bf10_1440w.jpg?source=d16d100b)

在使用 NebulaGraph 前，我们电商领域的精准推荐一直存在挑战。我们之前主要依赖 Elasticsearch 进行推荐，这种方式主要基于客户输入的关键词，比如螺丝的型号或规格，然后与我们的产品名称和属性进行匹配。然而，这种简单的关键词匹配方式对用户的真实意图分析不够全面，较难提供个性化的精准推荐。

我们有自己的线上商城，包括官网、App、小程序，对基础用户信息是有记录的，因此，我们计划引入擅长处理实体关系的 NebulaGraph 图数据库，利用用户特征和用户与商品的行为关系数据，构建更智能的推荐系统。

在引入 NebulaGraph 进行推荐和搜索优化的过程中，我们构建了一个完整的数据处理流程，解决传统推荐系统中的痛点。

![](https://picx.zhimg.com/80/v2-6a68fdfef27fa3413a6267f65cefdfad_1440w.jpg?source=d16d100b)

1.**数据输入与建模**

我们首先将线上的用户行为数据（如浏览、点击、购买等）和商品数据（如价格、类别、品牌等）作为输入。这些数据通过数据处理工具（如 Flink 和 DataX）进行清洗和转换，并加载到 NebulaGraph 中进行图建模。

2.**图数据库结构**

在 NebulaGraph 中，我们构建了一个以商品和用户为核心的图结构。商品节点包含价格、类别、品牌等属性，而用户节点则关联到客户信息。用户与商品之间的关系通过行为轨迹（如浏览、点击、购买、收藏等）建立，形成一个复杂的关系网络。

3.**实时特征提取与推荐优化**

通过 NebulaGraph 的原生 nGQL 查询语言，我们能够实时提取用户在平台上的行为特征，如浏览时长、点击次数、品牌偏好、价格偏好等。这些特征通过 API 接口实时返回给搜索引擎和推荐系统。

在推荐系统中，这些实时特征被用于优化召回和排序过程。具体来说：

* 召回阶段：引入实时特征以生成更相关的候选商品集合。

* 排序阶段：利用特征对候选商品进行排序，确保推荐结果更符合用户偏好。

这种优化显著提升了推荐的准确性和个性化程度，尤其是在新客户冷启动场景中。对于新客户，我们在注册时识别其行业和区域信息，并根据历史数据中相同行业或区域的用户行为，为其推荐相关商品。

**成果与规划**

**通过引入 NebulaGraph 进行推荐和搜索优化，我们在搜索推荐的点击率上取得了显著提升，整体提升了 15%，下单转化率提升 5%**。

未来，我们计划拓展更多关系数据维度（如客户需求采集），进一步提升推荐精准性，并引入 AI 实时学习机制，动态适应用户行为变化，实现推荐系统的自我优化，为更多用户提供了一个更加智能和个性化的购物体验。

## （二）应用场景之供应链

![](https://pic1.zhimg.com/80/v2-60027d0a73dbab04b24b2b4363038b7e_1440w.jpg?source=d16d100b)


在震坤行的供应链管理中，我们面临四个主要痛点，这些痛点影响了我们的运营效率和客户体验。

* **供应商整合与采购成本**：我们对接的供应商类型多样，包括原厂、代理和贸易商。由于缺乏统一的供应商信息整合，我们在采购决策时面临信息割裂的问题。

* **库存管理**：震坤行在全国拥有 32 个仓库，其中包括专门存储化学品和危险品的特殊仓库。之前的库存管理是单节点的，无法实现全国库存的全局可视化管理

* **履约协调**：客户订单处理需要智能选择发货仓库，以满足客户的交货时间和地址要求。

* **交付精准度**：在交付环节，我们面临信息不通畅、路径规划低效和服务体验受损的问题。物流信息查询困难、交货时间预测不准确以及配送路线不佳都影响了客户体验。

![](https://pic1.zhimg.com/80/v2-7028e0f1f45e4058da0b0ff3dcc00e91_1440w.jpg?source=d16d100b)

震坤行的供应链网络以商品为核心，客户需求驱动整个流程。商品从供应商流向仓库，再通过物流网络精准交付给客户。在 NebulaGraph 的支持下，从采购、库存、履约到最终交付，我们构建了一个高效、可视化的供应链网络。

1.**采购决策**

![](https://picx.zhimg.com/80/v2-f6e405faceebccc1be423c1bc770ded7_1440w.jpg?source=d16d100b)

客户订单是采购决策的起点。当客户订单提交后，系统会根据订单中的商品需求、数量、交货地址等信息，结合商品的价格、运费和交期等属性，在 NebulaGraph 中进行智能分析。通过实时查询和特征提取，系统会综合评估商品的评价、运费等信息，智能选择最合适的供应商渠道。最终，通过智能采购决策，系统自动推荐供应商和备选供应商，帮助公司优化采购成本，同时确保客户订单的最佳交付效果。

2.**库存管理**

![](https://picx.zhimg.com/80/v2-15e2badb215409141b9ba695de381b35_1440w.jpg?source=d16d100b)


我们的商品在库存中按照批次、数量、状态（如商品是否完好无损、存放时长）等属性进行管理。通过实时数据共享，仓库运营人员可以即时查询到商品在全国不同仓库的状态，从而更好地进行上下架操作和库存管理，制定更有效的库存策略，减少积压商品的占比，并实现联合库存管理和智能补货。

3.**智能履约**

![](https://pic1.zhimg.com/80/v2-9d06a600e2b75f6a585c28ca3b621821_1440w.jpg?source=d16d100b)


我们通过智能履约系统优化了从客户订单到物流配送的整个流程。当客户订单提交后，系统会根据订单中的需求数量、要求交期和收货地址等信息，智能检测并分配库存。例如，如果客户需要 100 个商品，系统会从不同仓库智能分配库存，可能从 A 仓库发 50 个，从 B 仓库发 50 个，然后统一配送。这种智能库存管理不仅提高了库存周转率，还降低了仓储成本，优化了整体供应链效率。

4.**精准交付**

![](https://picx.zhimg.com/80/v2-310e9ca1c29df3f192f59532cbc49708_1440w.jpg?source=d16d100b)


当客户订单生成后，系统会从相应仓库出货，并将订单信息实时传输到物流中心，如不同仓库库存和车队的发货信息。我们会对这些信息进行全局优化，例如，如果两个订单需要运往同一地区，系统会智能合并订单，使用同一辆车进行配送，从而降低运输成本。此外，我们还利用实时物流共享和 NebulaGraph 最短路径算法，优化配送路线，确保货物能够按时、高效地送达客户手中。

**成果**

* **客户满意度提升：透明的物流信息、精准的交付和高效的履约流程，显著提升了客户满意度，客户售后工单数减少20%**。

* 智能化与自动化：基于 NebulaGraph 的图算法（如最短路径算法、协同过滤算法等）可以自动优化库存、采购、履约和配送等环节，减少人为干预。此外，我们通过 NebulaGraph 搭建的智能供应链系统能够快速响应市场变化，提升竞争力。

* **成本降低与效率提升：通过优化库存管理、采购策略和配送路线，显著降低了运营成本，有货率提升15%，呆滞库存减少10%**。

#  四、未来规划

## （一）企业级知识库

![](https://pica.zhimg.com/80/v2-e1ba86984282c3b89b7b762dfb61d6a3_1440w.jpg?source=d16d100b)


![](https://picx.zhimg.com/80/v2-bd71e0dcbd950912e1a55597461d330c_1440w.jpg?source=d16d100b)


我们正在与 NebulaGrph GenAI 团队规划构建属于震坤行的企业级知识库，希望能高效整合结构化和非结构化数据，让我们的内部团队，如销售、客服、运营等人员，通过知识库实现智能问答，快速获取所需信息，提高工作效率。

## （二）智能风控体系

![](https://picx.zhimg.com/80/v2-38f57f85e773d82a36ccb48a7afc2877_1440w.jpg?source=d16d100b)

![](https://picx.zhimg.com/80/v2-a1b339e5f1f3c2f7af9cb2b5bd624e89_1440w.jpg?source=d16d100b)


我们亦在探索通过 NebulaGraph 去构建一个智能风控体系，用于全面识别和管理客户与供应商的潜在风险。风控主体分为客户、供应商两类，基于工商信息、企业征信、历史履约信息、新闻舆情等数据构建风控网络，通过子公司、股权、关键任职关系等数据识别客户和供应商的关系，做到客商风控一体。

如客户进行交易时，系统实时分析客户交易行为及司法风险，同时关联得到相关供应商的经营风险和采购行为，将业务规则映射 nGQL 抽取出客商风控特征，补充使用社区发现算法，判断是否存在欺诈风险，降低供应链风险。

# 五、总结

NebulaGraph 在震坤行的落地，是一次技术赋能业务的深度实践。通过强大的关系分析与处理能力，震坤行在精准推荐、供应链优化等业务场景取得了显著成果。精准推荐从“猜你喜欢”进化为“懂你需要”，供应链从“被动响应”转变为“主动优化”，客户满意度和运营效率双双提升。

未来，震坤行与 NebulaGraph 将进一步探索知识库和智能风控的深度应用，用 AI 技术重塑工业品电商的未来，释放更大的数字化转型潜力。

「ps：本文整理自震坤行在 NebulaGraph 社区 nMeetup 上的分享，震坤行目前已升级为 NebulaGraph 企业版」

本文从业务痛点、NebulaGraph 选型与架构、业务场景、未来规划等方面，介绍 NebulaGraph 在震坤行的应用实践。

震坤行工业超市全链路优化｜推荐成单与供应链管理效益均提升 15 %

> 导读： 
作者郑皓月，携程集团高级云原生研发工程师，专注于分布式存储领域。
图数据库在携程是首次落地，为接入携程集团研发体系适配现有系统，**自 2021 年起，郑老师及其团队对NebulaGraph 进行了一系列定制化改造。截止 2024 年，已有包括酒店、机票、金融在内的 16 个部门接入 NebulaGraph.** 
本文从 NebulaGraph 架构、部署及客户端改造等方面，介绍携程集团维护多云集群下多套 NebulaGraph 环境的经验，与三中心、跨域多活的部署策略。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/0414banner-02.jpg)



# 一、背景

为了满足越来越多 BU 对知识图谱、地理信息查询，图推理等业务场景的需求，自 2021 年起，我们首次尝试在携程的基础设施中引入了图技术。

在评估多种图数据库产品后，考虑到 NebulaGraph 采用计算存储分离的架构，具有高可扩展性，使用 Raft 协议保证数据的强一致性，支持千亿级超大规模数据集，并且 NebulaGraph 社区活跃，响应速度快，我们最终选择了 NebulaGraph 来构建我们的图数据库平台。

# 二、NebulaGraph 平台架构

## （一）架构概览

![](https://pic1.zhimg.com/80/v2-1455f18f3395859543db51daa4902cd5_1440w.jpg?source=d16d100b)

NebulaGraph 平台的架构设计旨在提供高效、可扩展且易于管理的图数据库服务。该平台基于 Kubernetes 进行部署，利用 Custom Resource Definitions（CRD）来管理 Graph、Meta 和 Storage 三个关键的 StatefulSets. 每个 StatefulSet 都包含了一个 NebulaGraph 服务容器以及一个 Sidecar 用于收集核心指标。

我们根据集群的类型，为部署在不同 Kubernetes 集群（三机房部署）的 MetaService 申请 DNS 用于服务发现，属于同一个 Kubernetes 集群(单机房部署或蓝绿集群)的 MetaService 则以 FQDN 的形式来组织。

首先，用户在 PaaS 平台申请图数据库资源。随后，InfinityStones 运维支撑平台通过调用 Kubernetes Client API 来生成相应的 CRD. 一旦 Operator 检测到 CRD 变更，将会在 Kubernetes 集群中创建对应的资源。Sidecar 会将采集到的 NebulaGraph 服务指标推送至 VictoriaMetrics，并最终在 Grafana 监控告警平台上展示，为用户提供实时的系统状态监控。

此外，集群信息会被注册到 Qconfig 配置中心，应用端通过拉取 Qconfig 中对应的配置来访问集群。用户可以在 SiteController 流量分发控制平台上进行自主路由，以优化流量分配和提升服务性能。

##  （二）隔离级别

![](https://picx.zhimg.com/80/v2-87868e203c2bef6a10737de54ccb2e03_1440w.jpg?source=d16d100b)


通过调研 NebulaGraph 集群的部署方式，发现大部分公司在部署集群时采用的是集群内多 Space 租户的形式，也就是只部署少量 NebulaGraph 集群，集群内部通过业务场景划分为多个 Space 分配给用户使用, Space 之间存在资源竞争，隔离等级低，一旦宿主机发生故障将会有多个用户受到影响，但是运维简单，有新用户接入时只需创建 Space，集群资源利用率高。

考虑到不同用户对集群资源的使用跟业务类型强相关，差距较大，我们采用单集群单 Space 租户的集群级别隔离，针对每个用户的业务创建新集群，由 Kubernetes 调度器进度调度分配，隔离等级高，故障影响范围小，但可能会造成一定程度的资源浪费。

##  （三）部署策略

我们提供了三种部署策略以适应不同的业务需求。

1. 单机房部署策略

![](https://pica.zhimg.com/80/v2-1e3e077498ecc08ce621fe2b069c02bb_1440w.jpg?source=d16d100b)


单机房部署策略将集群的 Graph、Meta 和 Storage 服务集中部署在一个 IDC 内。避免了集群内部节点跨机房通信问题，通过多副本的方式保证高可用。但应用与集群之间可能存在跨机房调用，并且无法避免机房级宕机导致的服务不可用，适用于非核心应用。

2. 三中心部署策略

![](https://picx.zhimg.com/80/v2-1e3e077498ecc08ce621fe2b069c02bb_1440w.jpg?source=d16d100b)


三中心部署策略将 Graph、Meta 和 Storage 服务被分别部署在三个不同的 IDC 中。任一机房宕机，集群仍然能够提供服务，从而实现了机房级的容灾保障。各 IDC 的数据通过 Raft 协议保证强一致性，适用于核心应用。

然而，由于集群内部节点存在跨机房通信，会带来一定程度的性能损耗。考虑到不同用户对集群资源的使用跟业务类型强相关，差距较大，我们采用单集群单 Space 租户的集群级别隔离，针对每个用户的业务创建新集群，由 Kubernetes 调度器进度调度分配，隔离等级高，故障影响范围小，但可能会造成一定程度的资源浪费。

3. 跨域多活部署

![](https://picx.zhimg.com/80/v2-e5e9cae393167216efba2bff282bf5f3_1440w.jpg?source=d16d100b)


为解决上述痛点，我们实现了跨域多活部署，也就是蓝绿集群。将完整的集群部署在多个 IDC 中，通过应用端双写来保证集群间数据一致性。客户端可以选择就近访问同 IDC 的集群来减少网络开销。

图中是一个典型的应用端双写保证集群间数据一致性的例子。首先，应用端将数据变更推送到消息队列，例如 Kafka, 部署在不同 IDC 的 Service 再通过不同的 Consumer group 来消费同一份数据，将数据变更写入到对应 IDC 的集群中。

##  （四）部署成效

![](https://picx.zhimg.com/80/v2-310d2c3da526077789a92d7502e0844f_1440w.jpg?source=d16d100b)


这是我们生产环境中酒店业务蓝绿部署和三机房部署的对比，可以看到蓝绿集群的访问延迟相比三机房部署降低了约一半。蓝绿双活部署是在性能和可用性上一个折中的选择，减少了大约 70% 查询过程中数据跨域带来的网络性能损耗，同时提供了机房级容灾保障，ATP 能达到 4 个 9. 目前我们将跨域双活扩展到了跨域多活，支持在多个 IDC 中部署集群。

# 三、NebulaGraph 客户端改造

##  （一）读写分离

![](https://picx.zhimg.com/80/v2-791f5443ad22b2e79fa2e079a20cf2b7_1440w.jpg?source=d16d100b)


对于蓝绿集群，我们使用双写的方式保证数据一致性。在发生故障时，我们希望访问故障 IDC 的应用端能继续访问另一个集群，而不会将本 IDC 的数据重复写入，因此读和写的逻辑通常是不同的。我们基于 IDC 和访问策略构造了不同的 nebula pool.

对于查询操作（如 match、go、show、describe），客户端将访问 Read Pool，而例如 create, drop，insert， delete 等 schema 定义和数据操控操作将访问write pool. 如果访问策略为就近访问，我们会将 read pool 和 write pool 合并。

我们还增加了流量分配功能，访问策略为"all" 时，通过权重轮询部署在不同 IDC 的集群，可以达到按比例分配访问流量的目的，从而实现负载均衡。

当路由策略设置为"read near"或"write near"时，客户端只会访问同属一个 IDC 的 NebulaGraph 集群，实现就近访问。如果访问策略设置为"all"，代表客户端可以访问所有集群，并且将根据流量分配策略按权重轮询多个 Nebula 集群，实现流量分发。

##  （二）故障切换

![](https://picx.zhimg.com/80/v2-5924ca7b6cd51fc1467c23e7eef61e21_1440w.jpg?source=d16d100b)


我们通过将集群信息注册到 Qconfig 配置中心， 实现了 NebulaGraph 配置的热推送。任何配置的修改都会实时推送到应用端，使客户端能够根据最新的集群配置来初始化新的连接池，从而进行正确的路由。我们还在 Sitecontroller 平台上集成了流量分配和访问策略切换的功能，用户可以根据业务需求自行调整配置。

##  （三）Session 管理

![](https://pica.zhimg.com/80/v2-5d5a9930ba54c92747223cfcc6486c84_1440w.jpg?source=d16d100b)


我们在初次使用 NebulaGraph 时，使用的是 2.5.0 版本，当时客户端的一些管理功能还比较薄弱，例如多线程环境下访问 Session 时可能存在线程不安全的问题，以及 Session 过期或失效需要用户自行处理。因此，我们对客户端进行了一些改造。

每一个 SessionHolder 都会维护一个基于访问策略和 IDC 构建的 Sessionmap，创建阻塞队列来管理 Session 的数量和版本，当管理中心有配置变更时，将会根据最新的配置释放和重建 Session 队列。客户端尝试从 Session 队列中获取 Session，通过 borrow and return的方式，一个执行器只能获得一个 Session，避免了 Session 共用带来的问题。

为增强 Session 复用，我们将根据执行结果来判断是否需要释放 Session. 例如因为网络抖动或查询语法错误导致的执行失败，没有必要释放重建 Session, 进而对 Meta 造成压力。Graph 每 10 秒会把 Session 信息持久化到 Meta，如果 Session 永不过期，Meta 会产生大量 Wal，负担很重。因此，我们将 Session 的过期时间设置为 24 小时，在获取到过期 Session 时，会重试一次执行，以平衡 Session 复用和 Meta 负载。

在实际生产中，我们注意到用户在执行周期性任务时可能会遇到 Session 批量过期的情况。为了解决这一问题，我们在将 Session 放回队列时会记录其最后使用时间。如果发现 Session 可能已经过期，先执行一次检查操作，以确定其是否仍然有效。如果 Session 确实失效，将重试直至获取到有效的 Session.

##  （四）语句生成器封装

![](https://picx.zhimg.com/80/v2-e712c0781029d07105882c6df9562542_1440w.jpg?source=d16d100b)

NebulaGraph 提供的 Opencypher 和自研的 nGQL 语法都是声明式语言，风格上类似 SQL, 对于用户来说易上手，但是在使用过程中不容易埋点监控。基于这个原因，我们重新封装了一个过程式语句生成器，以函数式数据流的方式重写了 nGQL 语法，接入了公司的监控日志指标平台，保证了 NebulaGraph 服务的可观测性，帮助用户迅速排障。

# 四、调优实践

最后，我还想分享一下我们在 NebulaGraph 实际落地过程中遇到的一些性能问题及调优实践。

![](https://pic1.zhimg.com/80/v2-53bee016052bd76d38d292c9e57585cf_1440w.jpg?source=d16d100b)

国际机票拆票集群在 AWS 的集群配置是 7 个 16c128g600g 的 Storage 节点，以及 8 个 4c16g10g 的 Graph节点，这样一个集群每月成本大概是 4.5w 人民币。

当时集群边写入 QPS 约 2w+，边删除 QPS 约 300-1000，宿主机的 CPU 利用率达到 50%，机票团队增加了新的数据源，希望我们能在不扩容的情况下新增一种边类型的写入，QPS 大概会增加 23%。除了 blockcache 的配置是 40G，大约 Storage节点内存的1/3，以及根据机器的规格调整了一些线程数外，其他的参数都是 NebulaGraph 的默认配置。

![](https://picx.zhimg.com/80/v2-9179c8f11479518deb3ad597b0610f11_1440w.jpg?source=d16d100b)

为了满足机票团队的需求，我们对 RocksDB 以及一些 NebulaGraph 的参数进行了调整。

write_buffer_size 默认是 256M, max_write_buffer_number 为 8，也就是说 memtable 大小是 256M,有 8个 memtable,而 target_file_size_base 默认是64M，也就是说 memtable 每 flush 一次，会生成 4 个 sst.

* 调整 target_file_size_base 为 256M，增加 sst 大小，减少 compact 频率，sst 落地后变为 256M，此时 CPU 利用率,io write 频率无明显变化，每次 io write 数据量尖峰变高。

* 调整 min_write_buffer_number_to_merge 为 4(默认为1)，每 4 个 memtable 写满 flush 一次，减少了 flush 的频率，io write 频率明显下降，CPU 使用率波动较之前平缓。

* 调整 level0_slowdown_writes_trigger 为 20，当 L0 文件数达到 20 的时候将会降低写入速度，这个参数默认为 8，跟 memtable 的数量一样，可能会造成 write stall.

* 调整 level0_file_num_compaction_trigger 为 10，当 L0 文件数达到 10 时，触发 L0 到 L1 compaction. level0_stop_writes_trigger 为 40，当 L0 文件数达到 40 时，停止写入。此时 io write 频率进一步下降。

* 调整 rocksdb_rate_limit，限制写入速度为 20MB/s，该参数默认没有设置，据我们观察大约为 50MB/s。该参数为 NebulaGraph 封装参数，并非 Rocksdb 本身的参数。此时 io write 尖峰基本消除，相较初始 Storage，CPU 利用率明显更加平滑。磁盘读写的频率下降非常明显，在接入新边类型数据后，可以看到边插入速率大约增加了 700，而 Storage CPU 无明显增长。

# 五、未来展望

![](https://picx.zhimg.com/80/v2-d10303c2ca64439ca5da50b00110a819_1440w.jpg?source=d16d100b)


##  （一）故障感知自动切换

目前，当机房发生故障时，用户需要到 SiteController 平台手动调整路由访问策略，人为介入可能会导致响应不及时。未来，我们期望客户端能够感知机房级故障并且自动切换访问策略。

##  （二）Raft Listener 实现集群间数据同步

为了解决集群间的数据一致性问题，我们计划引入 Raft Listener 机制来实现数据同步。在现有的架构中，集群间需要通过双写来保证数据一致性，而海外集群目前只能作为独立集群存在，亟需数据同步功能。Listener 在 Raft 中并不参与投票，只是负责监听，Meta 和 Storage leader 在接受到写请求时，除了同步一份数据给 Follower，也会同步一份数据给 Listener,在获得同步日志后，Listener 可以将不同操作的数据组装成一个请求发送给另一个集群，从而实现数据同步。

通过这些未来的改进，NebulaGraph 将提供更加稳定、高效和自动化的图数据库服务，满足携程业务的不断增长和变化的需求。

---

推荐阅读⬇️

[携程 x NebulaGraph｜业务增益 32%，NebulaGraph 在携程风控场景下的落地实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247512477&idx=1&sn=cc847b80046a99937d6b3ef33ad9287f&scene=21#wechat_redirect)

NebulaGraph 在携程集团的应用与实践

携程集团千亿级全场景业务实践｜NebulaGraph 实现 23% QPS 跃升与毫秒级响应

> 关于作者：郝鑫，Airwallex 空中云汇风控平台工程师，nebula-go Maintainer.自 2023 年底起，重点做图计算相关工作，业务场景侧重于风控。

![](https://pic1.zhimg.com/80/v2-94c6811f5a30542210afda39034a62c8_1440w.jpg?source=d16d100b)


# 一、Airwallex 空中云汇 

作为知名的全球支付及金融平台，Airwallex 空中云汇致力于为企业提供一站式跨境支付解决方案。

我们从实际业务场景入手，来让大家更了解 Airwallex 空中云汇。大家平时在购物、玩游戏、订阅视频网站平台，或者使用一些付费软件时，都会有不同产品下的跨境支付场景，包括刷卡支付或者定时订阅支付。这些支付服务的提供方包括游戏公司、电商平台，或者其他平台上的商户。

而 Airwallex 空中云汇，其实就站在这些企业的背后，为这些企业提供收单、收款以及资金管理相关的服务。

![](https://picx.zhimg.com/80/v2-a3d025ac4f0745ba003aedd7f21f1a09_1440w.jpg?source=d16d100b)


在跨境场景下，我们面临的客户形式和背景会非常多样化。

一方面其中有一些客户是游戏公司，面向不同国家的用户提供一个提供游戏内购款相关的产品；还有一些是电商平台，包括自营平台和类似于淘宝这种为不同商户提供服务的平台。

另一方面我们的客户不仅仅是这些平台本身，还包括平台上的商户。这些商户在法律上是一个独立的商业实体，所以我们需要对这些实体有非常清晰明确的认识。

![](https://picx.zhimg.com/80/v2-ed6e88edcd41dc2afd12e31d88bc8136_1440w.jpg?source=d16d100b)


以上展示的是一张从公司官网上摘录的 UI 界面，帮助大家感受 Airwallex 的业务场景。

# 二、NebulaGraph 的应用场景

我们把 NebulaGraph 的使用场景分为四个主要类目：

![](https://picx.zhimg.com/80/v2-3c850bcf5bc655ec9b3f6a6187d278a3_1440w.jpg?source=d16d100b)


# **（一）客户关系洞察**

刚才已经简单提到，在跨境场景下，不同国家的法律法规有其特殊性，商业实体是法律上的基本单位，我们需要对这些实体进行分类和关联。这有助于我们了解客户所在地的法律法规和业务范围，确保合规性。

**1. 个人信息关联**

* 商业实体的授权人和法人：这些人的信息需要与商业实体相关联，以确保我们了解谁在实际控制和管理这些实体。

* 注册账户的实际操作者：当个人注册并使用我们的服务时，他们的邮箱、手机号等信息需要与他们的账户相关联，这有助于我们在需要时进行身份验证和风险评估。

**2. 设备信息关联**

涉及客户使用的设备，如 IP 地址、设备 ID 等。这些信息可以帮助我们识别异常登录行为，例如从不寻常的地理位置或设备进行的登录。

**3. 网络信息关联**

包括客户的网络行为和交易模式。通过分析客户的网络活动，我们可以识别异常的交易模式或潜在的风险交易。例如，频繁的大额交易或在短时间内从多个不同地点进行的交易都可能引发警报。

**4. 人脸信息关联**

这是生物识别技术的一部分，用于验证客户身份。

# **（二）实时交易关联**

我们实时交易的时候，需要用 NebulaGraph 进行一些交易的关联。

设备信息关联，与 KYC 场景下的设备信息关联存在差异，这里的设备信息主要来源于集成了 Airwallex SDK 的支付组件。当用户进行支付操作时，会应用 Airwallex 不同平台的 SDK（移动端，网页端等），用户追踪设备 ID，设备型号，IP 地址等信息。

支付和收款信息的关联主要用于验证交易的合法性和安全性；在电商环境下，账单信息关联是识别异常购买模式和潜在欺诈行为的关键，而物流信息关联主要用于追踪商品流向和确保交易的完整性。

# **（三）模型特征提取**

在模型特征提取方面，我们并不是直接使用原始数据，而是先对数据进行处理，生成特征。这些特征随后被用于不同模型的训练和实时推断。在线图服务运行时，会定期生成数据快照用于模型训练，同时在线服务也需要实时接口来计算特征，用于模型推断。

# **（四）可视化交互**

我们目前的实现较为简单，主要面向内部运营人员。我们提供了一些 Web 页面，允许运营人员根据自身需求输入信息并进行操作，以实现按需查询和交互。

# 三、Why NebulaGraph？


# **（一）背景**


上述提到的客户关系洞察（KYC，Know Your Customer）是风控领域确保客户身份真实性和评估其风险状况的重要流程。它不仅在新客户注册时进行，还贯穿于客户整个生命周期，以应对客户资料或交易行为的变化。

KYC 的核心在于验证客户身份、了解其财务状况和风险特征，从而防止欺诈和金融犯罪。

![](https://pic1.zhimg.com/80/v2-ff2ffeb054f41af74c0f2d785f51290d_1440w.jpg?source=d16d100b)


**图关系是 KYC 的自然表征。通过图数据库，可以将客户、账户、设备、交易等信息以节点和边的形式进行建模，直观地展示客户之间的复杂关联。例如，法人与商业实体的关联、账户与设备的关联等**。这种结构化表示不仅提升了数据的可读性，还使得异常行为的识别更加高效，比如通过关联分析发现潜在的欺诈链条。

**因此，我们使用 NebulaGraph 其实是一种非常水到渠成的选择**。

# **（二）面临的问题**

在引入 NebulaGraph 之前，我们使用的是一个简单的 Python 图服务，主要用于处理一些基础的图关系应用。当时公司还处于早期阶段，数据量相对较小，因此我们从离线数仓中读取所有数据，通过传统的操作提取点和边的信息，并将其存储在内存中构图。

![](https://pic1.zhimg.com/80/v2-d1c129d42406115b581748feede2e935_1440w.jpg?source=d16d100b)


这种架构在数据量较小时表现尚可，但随着业务的发展，逐渐暴露出一些问题。

首先，稳定性不足，因为需要定时更新数据，每隔 10 分钟就需要重新读取和构图，这个过程容易出现故障。其次，内存效率较低，尤其是在数据量逐渐增加的情况下，内存占用成为一个瓶颈。此外，查询语言的表现力有限，无法满足复杂场景的需求，导致开发效率低下。这些问题促使我们考虑引入图数据库来解决业务中的挑战。

# **（三）NebulaGraph 选型**

![](https://picx.zhimg.com/80/v2-969a11bff0b9fc4f1a0625e61d27baaa_1440w.jpg?source=d16d100b)

**当时在选型时，我们对比测试了多个图数据库。我们淘汰了性能测试中表现不佳的一些图数据库，即使个别图数据库与 NebulaGraph 性能接近，但在功能全面性上有所欠缺。此外， NebulaGraph 拥有丰富的企业应用案例也是我们选择它的重要因素**。

# 四、系统架构设计

# **（一）客户关系系统架构**


### **客户关系的构图**


![](https://pica.zhimg.com/80/v2-708c65b27ff8c1eed1b17741d89f887a_1440w.jpg?source=d16d100b)

如图所示，我们对账户节点进行了高度简化。实际上，我们内部的账户信息是一个层级结构，因为每个子账户实际上都是一个独立的公司。

我们构建的是一个异构图，这种结构有几个显著的优点：

**1. 易于满足不同的查询场景**

异构图能够灵活地适应多种查询需求。例如，我们可以轻松地查询某个账户的关联信息，或者分析账户之间的交易模式。

**2. 易于引入新的关系类型**

随着业务的发展，我们可能会遇到新的数据类型或关系。异构图的灵活性使得添加这些新的关系类型变得相对简单，只需要在图中添加相应的节点和边。

**3. 易于结合 TTL 进行数据清理**

TTL（Time to Live）机制可以帮助我们自动清理过期的数据，确保图数据库中的信息保持最新和相关。

在过去的几年中，我们不断引入新的关系类型，使得我们的图结构比上图上显示的更为丰富。这种灵活性不仅满足了我们当前的需求，还为未来可能的新发展提供了便利。我们可以在不同的边上配置不同的属性和权重，以便进行更精细的数据分析和清洗。

### **系统架构**


![](https://picx.zhimg.com/80/v2-92e21f24d18fbc184a660fc2a461777a_1440w.jpg?source=d16d100b)


**1. 数据写入**

* 小时级批处理（全量）：通过一个中等量级的属性更新，将所有数据一次性写入到数据库。

* 业务系统实时数据补齐（增量）：在新客户注册时，由于没有历史数据，业务系统会通过 API 实时补齐数据，并写入到数据库中。

**2. Schema First**

* Schema as Code：所有字段的定义和变更都在代码中完成，自动生成功能确保了数据的一致性。

* 单一 Schema：既用于服务代码，同时也生成 ETL 的 Schema。这样可以确保数据的一致性和开发效率。

我们的图服务主要用于以下几个方面：

**1. 模型特征提取**

我们需要实时进行客户分析，以及其他不同场景下的交易和用户行为分析。

**2. 规则引擎**

这是我们内部的一个风控引擎，通过图的特征数据进行规则处理，最终做出不同的判断。

**3. 业务服务**

内部的其他业务服务可以利用图数据库的数据进行相应的处理。

**4. 可视化**

提供一些界面让运营人员进行查询和分析。


### **业务复杂性**


![](https://pic1.zhimg.com/80/v2-a4f44e084169e0a4775a2e5777164be5_1440w.jpg?source=d16d100b)

1. Schema复杂且易变

* 数据模式复杂，节点类型多样（约 10 多种），不同节点上的属性信息差异较大。

* 数据模式变更频繁，每月可能有局部调整，需要灵活的管理流程。

2. 数据逻辑变更与清洗

* 数据清洗和逻辑变更需要一个易于操作的流程，以应对业务的快速变化。



###  **应对策略**



1. 一处定义，动态生成

* 在代码中统一定义数据模式（Schema），每次代码提交时自动生成相应的数据模式定义。

* 修改字段名称、添加字段或调整属性时，只需在代码中操作，系统会自动生成变更语句并逐步完成自动变更。

2. TTL + 全量写入

* 使用 TTL 机制结合全量写入的方式，确保数据的时效性和完整性。

![](https://pica.zhimg.com/80/v2-36245b17b96fa6bd09d08abf2caa169e_1440w.jpg?source=d16d100b)


我们采用了一种 Declarative 的 Schema 管理方式。 当我们对一个字段进行命名、添加、属性信息进行修改的时候的时候，会在内部自动生成相应的变更语句。

![](https://pic1.zhimg.com/80/v2-2a58aa041e9f347a551348ffd3427d55_1440w.jpg?source=d16d100b)

在查询结果映射方面，我们采用了“声明即所得”的方式。

通过在代码中定义结构体，并使用注解直接映射查询结果中的字段，查询结果会自动填充到对应的结构体字段中，无需手动处理字段映射。此外，通过 SDK 或接口动态获取字段信息，确保每次查询都能正确映射到最新的 Schema，避免了因字段变化导致的查询错误，提高了系统的稳定性。

# **（二）交易关联系统架构**

![](https://picx.zhimg.com/80/v2-c14b623a5b38c00204cc4a1e989af680_1440w.jpg?source=d16d100b)

![](https://pica.zhimg.com/80/v2-cf52f1a4b3574823aa7e5da01a6124a4_1440w.jpg?source=d16d100b)

![](https://pic1.zhimg.com/80/v2-0e6102b31d9ff1349305f9d22a8a0e03_1440w.jpg?source=d16d100b)


在交易关联系统中，与客户关系系统存在较大差异，在这里，我们对实时性要求更高，因此我们采用了分离计算、读时合并的架构。

历史数据（超过 4 小时）通过小时级批处理进行预计算，生成子图的点边信息，并存储在图数据库中。实时数据（4 小时以内）则通过 Kafka 实时获取上游交易的原始数据，在服务端进行拆分和构建后写入 NebulaGraph.

# 五、未来展望

![](https://picx.zhimg.com/80/v2-c7d3b5332dc8c536fa1f53dba99a8b76_1440w.jpg?source=d16d100b)

目前，单一 Nebula 集群在计算资源隔离方面存在不足，导致不同应用间的查询峰值会相互干扰，且一套集群无法同时满足 TP（事务处理）和 AP（分析处理）的目标。此外，图算法的支持也存在一定的开放性不足和生态不够丰富的问题。

在未来，我们希望能够改善这些问题，通过更好的资源隔离技术和更丰富的图算法生态，来提升系统的性能和可用性。我们期待与社区和其他开发者一起合作，共同推动技术的发展和生态的建设。

:grinning:
「ps：本文整理自 Airwallex 在 NebulaGraph 社区 nMeetup 上的分享，Airwallex 目前已升级为 NebulaGraph 企业版」

NebulaGraph 在 Airwallex 跨境金融风控的应用

导读：某全球知名信息与通信技术（ICT）解决方案供应商通过 NebulaGraph 构建了覆盖云原生 DevOps 全流程的图数据库管理平台，并有效优化了 NebulaGraph 的可维护性、安全性、可靠性。本文将深入探讨自动化部署、数据安全性和可靠性建设的关键策略，为数据库管理提供全面的解决方案。

![](https://pic1.zhimg.com/80/v2-5f936ec0018e8f6a09eade14d8a900f6_1440w.jpg?source=d16d100b)




# **一、引言**

## **（一）云原生DevOps**

首先，我们来谈谈“云原生 DevOps”.

“云原生”是一个合成词，由 ''Cloud'' 和 ''Native'' 组成，''Cloud'' 它指的是我们的应用程序开发是基于云上进行的。''Native'' 是一个理念，意味着我们在开发应用程序时，从设计之初就应考虑到它是在云上运行的，基于云上的资源进行开发。

**总之，我们在设计时不会过多关注底层细节，如资源物理集群信息，而是更聚焦于业务程序需求本身。**

## **（二）数据库平台能力建设**

我们终端云服务背后有很多云服务能力，比如我们手机后台的云服务能力。这些服务能力是基于云服务平台的能力构建的，涉及到各种能力的组件，比如数据的持久化。

数据持久化是在数据库平台上进行构建，**基于我们原有的能力结合 NebulaGraph 图数据库，已经有 20 + 业务使用数据库平台上的 NebulaGraph 能力，例如特征工厂、数据血缘、风控等**。我们为提高多个业需求和运维效率，将这些能力整合。

## **（三）业务背景**

![](https://pica.zhimg.com/80/v2-f0049a9492fda22090f2f0afcdf11081_1440w.jpg?source=d16d100b)


在计划构建图数据库平台时，我们关注几个关键信息：批量图数据库的集群维护、人力成本、专业技能要求、安全性、业务支撑要求等。这些挑战要求图数据库必须具备高可用性、高性能和高安全性。

最终我们选择了 NebulaGraph 构建来一个高效、可靠且安全的图数据库平台，以支持业务的快速发展。这个平台不仅能够处理大规模数据，还能够应对复杂的业务关系，同时保持高可用性和安全性。

# **二、整体架构**

我们的数据库平台主要分为两大板块：数据库治理和数据库引擎。

![](https://picx.zhimg.com/80/v2-2033f2685242e035d135cf6963f526d7_1440w.jpg?source=d16d100b)


数据访问框架的核心是 WiseDBA, 它是一个集成了 DevOps 理念的数据库治理平台，旨在实现变更自动化和数据同步合规。数据库治理模块涵盖了数据库的整个生命周期，包括设计、开发、发布和运维等，在每一个阶段，我们都提供了表设计工具、SQL 审核与发布工具等一系列工具，来提高治理效率。

数据库引擎通过同城双活和异地多活等方式保障高可用性，利用增量备份和快速恢复确保数据安全，同时优化了查询性能和数据处理能力，通过物理集群连接解决容量瓶颈，并实现数据库节点的弹性伸缩以适应业务需求变化。

我们的平台已经支持了多种数据库，包括 GaussDB、DCS(基于 Redis)、ClickHouse、NebulaGraph 以及 CSS(基于 Elasticsearch 构建的文档数据库).

通过这样的框架设计，能够为各种业务场景提供稳定、高效、安全的数据库服务。

# **三、NebulaGraph 引擎管理架构设计**

NebulaGraph 引擎管理架构设计是确保数据库稳定性和高效性的关键。这一架构设计提供了覆盖 DevOps 全流程的数据库治理能力，实现数据安全和数据隐私的全面防护。

![](https://pica.zhimg.com/80/v2-1855b6913a6ddd0f9344ec0fd6c45bb5_1440w.jpg?source=d16d100b)


## **（一）使用者视角**

**管控面**

各个治理工具覆盖了 DevOps 全流程，从设计、开发、发布、运维各阶段管控 NebulaGraph 数据库：

* 表设计工具：辅助用户设计数据库表结构。

* SQL 审核工具：在开发阶段审核 SQL 语句，确保质量。

* SQL 变更工具：管理数据库变更，确保变更的安全性和可追溯性。

* 性能诊断工具：提供性能诊断，帮助用户识别和解决性能问题。

* 健康巡检工具：定期检查数据库健康状况，预防潜在问题。

**运行面**

这部分是业务接入 SDK, 最终业务应用程序还是需连到机器上，进行数据的检索，我们增强了以下能力：

* 安全认证：确保业务应用程序与数据库之间的连接是安全的。

* 连接池：管理数据库连接，提高资源利用率。

* 自动重连：在连接断开时自动重新建立连接，保证业务连续性。

* 配置热生效：允许在不重启服务的情况下更新配置，提高灵活性。

* 主备切换：在主数据库出现问题时，自动切换到备份数据库，确保服务不中断且无感知。

## **（二）提供者视角**

**NebulaGraph 管理台**

NebulaGraph 管理台是 NebulaGraph 数据库治理的基石，它结合了治理工具，全面实现了数据库变更的自动化。管理台提供了实例管理、图空间账号管理、图空间管理和 Tag/Edge 管理功能，使得管理 NebulaGraph 的各项操作都变得简单高效。

**SDK 配置管理台**

SDK 配置管理台专注于业务接入的自动化。该管理台将接入规范集成到 SDK中，使得业务接入配置管理变得高效，包括连接池参数配置、数据库账号配置以及 SDK 配置下载等功能。

此外，SDK 配置管理台还提供了读写分离配置、DB 请求灰度配置功能，有助于业务在不同环境下实现平滑过渡，同时有效控制和管理潜在的风险。

通过这样的 NebulaGraph 引擎管理架构设计，屏蔽了 NebulaGraph 整个物理集群的组网部署信息，专注于业务逻辑的开发。

# **四、NebulaGraph 集群可维护性建设**

所谓“可维护性”，即通过自动化日常操作，屏蔽操作内部细节，提升批量集群的可维护性。

## **（一）简化安装过程及集群调参等动作，降低了业务试用接入门槛**

![](https://pic1.zhimg.com/80/v2-15483238693ce0fce33273ab42e96702_1440w.jpg?source=d16d100b)


一个图数据库集群的开通，如果按照传统方式做一个中间件引入、部署，整个流程十分繁杂。我们通过云原生 DevOps 的能力，把周边的组建整合起来，最终实现业务在部署集群的时候，只需选择部署的环境、集群名、图数据库版本等基础信息，以及业务关心的单云/双云、主机的规格、节点的个数、缩放空间，再点击立即创建后台，基本在 20 分钟以内就能完成整个集群的自动化部署。并且在完成自动化部署后，后台有自动化的能力把账号配置进行自动化处理。

## **（二）云原生-基础设施即代码方式申请实例、图空间、链接配置等**

![](https://pica.zhimg.com/80/v2-83b12e61a60a9d2def4cfd40720590a0_1440w.jpg?source=d16d100b)

在开发过程中，当研发需要一个新的图数据库引擎实例时，会以页面文本的方式描述所需的集群规格、磁盘大小、节点数等集群信息。这些描述信息会被基础设施即代码（IaC）平台执行，我们的后台会自动找到所申请的组件，组件后台再完成自动化的安装。在整个过程中，无需关注细节，因为 IaC 代码可以重复执行，进行调和，以达到目标状态。在整个过程中是无人值守的，IaC 代码跑完，就能实现开发需求。

## **（三）集群配置分级管控、配置飘移检测，降低集群运维风险**

![](https://picx.zhimg.com/80/v2-b4850b685404e6a0fe4072e8e7c9cf33_1440w.jpg?source=d16d100b)


做数据库平台最大的挑战是，在初始阶段，数据库通常以中间件的形式存在，由各个业务自行配置和维护。在维护过程中，分布式集群的多节点特性使得问题定位变得困难，一旦出现问题，不仅需要花费大量时间进行排查，并且在排查过程中，业务也会遭受损失。

因此，我们的配置管理进行了分级分类。

* 不开放部分配置给业务处理，以减少误操作风险。

* 提供 Agent 能力，通过 Agent 读取核心进程内存数据和本地配置文件数据，并将其存储到预设的空间中。

* 实现配置漂移检测，检测节点内配置是否生效以及节点间配置是否一致

# **五、NebulaGraph 集群数据安全性建设**

## **策略一：事前预防**

![](https://pica.zhimg.com/80/v2-df5f41257f6f2db924049df7eb10cabe_1440w.jpg?source=d16d100b)

1. 权限最小化

* 人员权限：将数据库操作权限按角色由高到低进行划分：DBA>运维 SRE>研发。

* 账号管理：

* 人机账号：控制账号的有效期，避免账号泄露导致未经授权的操作。

* 机器账号：分为治理账号和业务程序账号，治理账号用于 DevOps 流程中的设计工具，业务程序账号仅赋予应用程序所需的最小权限。

2. 管理操作工具化

* 引擎管理台：作为数据库平台的一部分，用于执行日常管理和监控任务。

* 数据库跳板机：作为进入数据库后台的跳板，通过严格的权限控制，只允许特定人员操作。

* 主机堡垒机：在跳板机无法解决问题时，连接到数据库集群，进行更深入的操作。这一层级的权限要求更高，通常由 DBA 执行。

## **策略二：事中拦截+事后恢复**

![](https://picx.zhimg.com/80/v2-32f12f6c446c1d79cf73f4ebc85299d9_1440w.jpg?source=d16d100b)

**事中拦截**

1. 版本测试与发布评估

在版本测试发布时，会对业务要执行的操作进行负面评估，即判断当前运营环境是否允许这样的操作，以及当前的情况是否合适。

2. 软删除机制

如果业务坚持要删除某个对象，NebulaGraph 会采取软删除的方式，即暂时禁用该对象，使其无法被业务使用。这样，如果业务发现误删了数据，可以迅速通过软删除的能力进行恢复。

**事后恢复**

1. 快速恢复能力

由于采用了软删除机制，当需要恢复数据时，只需将禁用的对象重新启用即可。这种方式比传统的硬删除后恢复要快得多。

2. 定期快照与备份

NebulaGraph 结合了社区提供的快照能力，定期将业务数据上传到 OBS 中。这样，即使数据被误删，也可以通过快照进行恢复。数据发现的越早，恢复的越快；发现的越晚，恢复成本越高。

# **六、NebulaGraph 集群可靠性建设**

在 NebulaGraph 的日常操作变更和数据安全防护方面，我们已经实施了工具化和相应的防护措施。然而，为了确保集群在运行或变更过程中不会出现可靠性问题，还需要进一步加强可靠性能力的建设。

## **（一）集群变更，业务不中断**

![](https://pica.zhimg.com/80/v2-28c28951c3e6a3d677fff5b1314ab094_1440w.jpg?source=d16d100b)


关键点在于我们将 NebulaGraph 的 SDK, 放在配置中心里，业务不感知这个连接，如 IP、账号密码等。另一方面，为了避免对业务造成影响，我们的图数据库管理平台是滚动升级，逐个节点进行循环执行。如果某个节点出现问题，我们有 NebulaGraph 作为兜底，比如我们发现某个节点有问题，暂时把它踢掉，通过间隔检查，发现问题已顺利解决，我们再把它加载过来。并且如果后期需要修改参数，业务也无需重启，利用热加载将其加载到 NebulaGraph 的 SDK 里。

## **（二）故障业务不中断——双云组网**

![](https://pica.zhimg.com/80/v2-07bdcfa59ae7d90095e783071903c5ed_1440w.jpg?source=d16d100b)


双云组网形式，有多种实现方式，比如通过业务双写的方式和利用集群本身的能力。我们的双云组网实现过程中，引入了 meta 、storage、graph. 在 meta 、storage 数据中加入鉴定组件，meta 和 storage 不参与选举，但负责接收并处理来自其他组件的数据副本。然后，这些数据会被同步到备集群中，整个过程中业务无需感知。

故障业务不中断——双云切换

![](https://picx.zhimg.com/80/v2-c9e113196b1eb664564542c725597706_1440w.jpg?source=d16d100b)


为了保障业务的连续性，NebulaGraph 集群采用了双云切换策略，该策略包括以下几个关键点：

* 对接注册中心：集群的链接信息被写入到注册中心，Nebula-SDK 从注册中心拉取配置，确保业务能够获取最新的集群配置信息。

* 读写分离：系统支持读写分离能力，可以在主、备集群之间分配读写请求，以提升查询性能。

* 主备切换：系统能够自动探测集群的健康情况。一旦发现集群异常，可以自动迁移到健康的集群，并进行回切，以保证业务的连续性。

双云切换流程

* 探测集群健康情况：业务 SDK 会定期检查集群的健康状态。

* 自动切换到健康集群：如果主集群出现故障，SDK 将自动切换到备集群，确保业务不受影响。

* 切流数据同步：在切换过程中，数据同步机制确保数据的一致性。

## **（三）节点指标&日志采集**

![](https://picx.zhimg.com/80/v2-2cbb249945d0f1b9f9abd5dc82426b06_1440w.jpg?source=d16d100b)

为了确保 NebulaGraph 集群的可靠性，我们实施了节点指标和日志的采集策略，这包括：

* 丰富的主机监控：对集群所在主机节点的 CPU、内存、磁盘空间等关键资源进行监控，确保资源使用情况在可控范围内。

* 分钟级 200+个指标监控：提供秒级的数据采集，支持超过 200 个指标的监控，这使得运维团队能够快速定位集群的性能瓶颈或异常。

* 灵活便捷的告警机制：当监控指标超出预设阈值时，系统会触发告警，通知运维人员及时采取措施，如扩容或优化配置。

# **七、未来规划**

**继续聚焦单节点故障自愈能力**

![](https://picx.zhimg.com/80/v2-f3a12794ba85ea3d3d0526406fe5a6df_1440w.jpg?source=d16d100b)

我们正在努力提升 NebulaGraph 集群在面对单节点故障时的自愈能力，以确保集群的稳定性和业务的连续性。

* 容量问题：单个大规模集群( 50+ 节点) Meta 进程可能会遇到性能瓶颈。我们正在对这一问题进行压测，以评估和解决可能出现的性能问题。

* 性能问题：在Flink 大规模实时写入的情况下，如何避免图查询能力受损。目前，我们采取的措施是实现读写分离，但这种分离是在双集群层面上进行的。在双云部署的环境下，一个集群负责写入操作，而另一个集群则专门处理读取请求，以此来优化性能。

NebulaGraph 图数据库平台的能力建设是一个持续进化的过程。我们将继续在云原生 DevOps 全流程中不断探索、优化，构建一个更加强大、安全、可靠的图数据库平台，以满足日益增长的业务需求和挑战。

如何构建覆盖云原生 DevOps 全流程的 NebulaGraph 图数据库管理平台