
> 导读：传统 RAG 遇瓶颈，复杂推理怎么办？ GraphRAG 正成为知识管理新利器。 但关键问题来了：GraphRAG 真的超越了 RAG 吗？GraphRAG 哪家强？GraphRAG 性能评估标准有哪些？面针对不同场景需求如何选择？香港理工大学等学者在 6 月 3 日发表论文，重磅推出首个大规模、领域特定基准 GraphRAG-Bench，为技术选型提供硬核依据。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/technology-popularization/GraphRAG-Bench-banner.png)

🔍本文翻译略有删减，论文原文如下

https://arxiv.org/pdf/2506.02404

  


# 一、摘要


图检索增强生成（Graph Retrieval-Augmented Generation, GraphRAG）因其在结构化组织领域特定语料库并提升复杂推理能力的潜力，正日益受到认可。然而，当前 GraphRAG 模型的评估主要依赖传统的问答数据集。这些数据集在问题广度和评估指标上存在局限性，无法全面衡量 GraphRAG 模型所带来的推理能力提升。

为弥补这一不足，我们提出了 GraphRAG-Bench，这是一个为严格评估 GraphRAG 模型而设计的大规模、领域特定基准。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/technology-popularization/overview-of-GraphRAG-Bench.jpg)

我们的基准具备三大优势：

*   **挑战性问题设计**： 包含大学水平、领域特定的问题，要求进行多跳推理，确保仅靠简单内容检索不足以解决问题。例如，部分问题涉及数学推理或编程。
    
*   **多样化任务覆盖**： 数据集涵盖广泛的推理任务类型，包括单项选择（MC）、判断正误（TF）、多项选择（MS）、开放式问答（OE）和填空（FB）。问题来源覆盖 20 本核心教材中的 16 个学科。
    
*   **全方位评估框架**： GraphRAG-Bench 提供了覆盖整个 GraphRAG 流程的全面评估，包括图构建、知识检索和答案生成。除了最终答案的正确性，它还评估推理过程的逻辑连贯性。
    

通过将九种前沿 GraphRAG 方法应用于 GraphRAG-Bench，我们量化了基于图的结构化如何提升模型推理能力。我们的分析揭示了关于图架构、检索效能和推理能力的关键见解，为业界研究提供了可操作的指导。

GraphRAG-Bench 的所有相关资源均已收集在：

https://github.com/jeremycp3/GraphRAG-Bench

  


## 二、研究背景


检索增强生成（Retrieval-Augmented Generation, RAG）已成为将大型语言模型（Large Language Models, LLMs）植根于外部知识的关键解决方案，用以缓解幻觉问题及领域知识匮乏的问题。通过从语料库中检索相关文本片段，RAG 为 LLM 注入事实性知识，以生成更可靠的输出。

然而，传统的 RAG 系统在处理复杂推理场景时仍不尽如人意。**RAG 中的扁平检索仅基于相似度匹配直接返回零碎的文本块，这限制了其对概念间复杂关系建模的能力，难以回答需要多跳推理、全局理解问题**。例如：

> “2008年雷曼兄弟破产事件对埃隆·马斯克的特斯拉公司有何影响？”

> “贸易政策变革事件的主要思想是什么？”

为应对这些局限，图检索增强生成（GraphRAG）被广泛研究，旨在以图的形式捕捉概念间的结构化知识。其中节点代表概念，边代表概念间的关系。GraphRAG 的最新进展可归纳为三个主要方向。

*   分层图构建方法，通过树形结构和社区检测来组织知识。
    
*   神经图检索方法，采用图神经网络编码器并结合专门的目标函数进行多跳推理。
    
*   动态知识集成系统，开发了与 LLM 紧密耦合的自适应图构建和遍历机制。
    

**通过将知识结构化为图，GraphRAG 不仅使 LLM 能够沿着显式关系路径进行遍历和推理，还能基于图结构推断隐含关系，从而支持更深层次的推理。**

然而，尽管前景广阔，现有的 GraphRAG 方法基准未能充分反映其在图结构上进行推理的性能。这些基准主要利用传统的问答数据集，如 HotpotQA 、2WikiMultiHopQA 和 MuSiQue ，这些数据集仅包含复杂度有限、答案简短的显式事实性问题，例如“Dambar Shah 的孙子是谁？”。

这些数据集存在三个关键局限：

*   仅包含常识性问题，这些问题可能已被 LLM 的训练语料覆盖。
    
*   通常仅需基于显式连接的单跳或浅层多跳推理，不足以探明图结构知识的独特优势。
    
*   答案形式单一： 多数答案为简短形式（名称、日期）或选择题，难以反映基于图的推理能力。
    

因此，我们提出一个研究问题：

**“GraphRAG 是否真正超越了传统 RAG，提升了模型的推理能力？”**

  


# 三、研究方法与实验设计



## （一）研究方法


### 1. 问题设计

为了在大学水平推理上评估 GraphRAG 框架，我们首先构建了一个权威教材语料库。从涵盖计算机科学 16 个不同子领域的 100 多份出版物出发，系统性地筛选出最具代表性的 20 本教材。我们定义了五种问题类型，每种针对 GraphRAG 推理能力的不同方面。最终选取出 1018 道高质量挑战性问题，覆盖了广泛的主题。

![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/technology-popularization/GraphRAG-Bench-question.jpg)

### 2. 语料库收集与处理


（1）预处理阶段区分 PDF 文本页与扫描页，分别采用直接提取和 OCR，并提取教材元数据（大纲、章节页码）。

（2）内容解析阶段：

*   使用 LayoutLMv3 进行多模态布局分析，分割页面为标题、段落等语义块
    
*   用 YOLO 模型检测并隔离数学公式区域避免 OCR 错误
    
*   对扫描页指定区域应用 OCR 获取文本
    

（3）后处理阶段通过 MinerU 工具按阅读顺序重组可能混乱的解析元素（文本、公式等）。

（4） 基于元数据构建四级层级结构（书名→章→节→知识单元），形成带结构标注的教材树。

### 3. 专家撰写推理依据

现有基准通常仅提供最终答案或显式图路径。相比之下，我们的数据集提供了专家撰写的推理依据，清晰阐述了解决每个问题所需的完整逻辑推进过程。

这些推理依据超越了简单的语料聚合，是结构化的叙述，能够：(i) 分离出前提概念，(ii) 描述这些概念间的关系，以及 (iii) 指明问题求解过程中应用的推理操作。

通过追踪逻辑推理和知识交互的每一步，我们可以评估 GraphRAG 模型是否真正生成了基于上下文的解释，还是仅仅利用了表面模式。

为实现细粒度、主题特定的评估，我们数据集中的每个问题都带有两个层级标签：一个宽泛的子领域（Level 1，例如“机器学习”）和一个更细粒度的概念（Level 2，例如“无监督学习”）。这些标注支撑了我们的后验分析。对于每个主题，我们不仅衡量模型答案的准确性，还衡量其生成的推理依据与标准依据的契合度。通过这种方式，我们将评估转化为一个多维过程，要求模型既要提供正确答案，也要生成忠实可信的推理模式。


## （二）实验设计


### 1. 评估指标


*   **图构建：**   
 
   **效率 (Efficiency)：** 构建完整图所需的时间。
    
  **成本 (Cost)：** 图构建过程中消耗的 token 数量。
    
  **组织度 (Organization)：** 构建图中非孤立节点所占的比例（衡量图的连通性）。
    

*   **知识检索：**   
    

   **索引时间 (Indexing time)：** 构建用于检索的向量数据库所需的时间。
    
  **平均检索时间 (Average retrieval time)：** 每个查询进行知识检索的平均耗时。此外，我们总结每种方法使用的检索操作对象（Retrieval operators）以评估其检索机制的复杂度。
    

*   **生成：**   
    
我们认为现有的精确匹配（exact match）指标并不合适，因为正确答案无需逐词对应。因此，本文引入了一个新指标：**准确率 (Accuracy)**，定义如下：

   **OE 和 FB 问题：** 将生成输出和标准答案通过我们设计的提示词（prompt）输入一个 LLM，该 LLM 基于语义对齐和正确性打分。
    
   **MC 和 TF 问题：** 答案正确得 1 分，否则 0 分。
    
  **MS 问题：** 完全正确得 1 分；部分正确得 0.5 分；错误得 0 分。
    

*   **推理依据：**
    

  **推理得分 (R, Reasoning Score)：** 我们设计了一个提示词，将 GraphRAG 方法生成的推理依据和标准依据输入一个 LLM，该 LLM 给出一个推理得分（R）以评估它们的语义对应和推理一致性。
    
   **答案相关推理得分 (AR, Answer-related Reasoning Score)：** 我们额外开发了 AR 指标，用于判断当模型准确回答问题时，其是否能提供正确的推理。此指标旨在区分模型是仅仅猜对了答案，还是确实通过合理的逻辑推理得出了正确答案，从而更全面地理解模型性能。
    


### 2. 实验设置

评估了九种前沿 GraphRAG 方法的性能，为确保所有方法公平比较，采用相同的 GPT-4o-mini 作为默认的大型语言模型。我们没有设置最大 token 长度来限制单个方法的性能。对于需要选择 top-k 的方法，我们统一设置 k=5。在文本分块方面，块大小统一设置为 1200 个token.

  


# 四、实验结果


## （一）图构建评估


![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/technology-popularization/graph-construction-process.jpg)


### 1.  Token 与时间成本

    

*   **树结构**的 Token 成本最低，因为它仅调用 LLM 生成摘要，但由于迭代聚类，耗时最长。
    
*   **段落图**的 Token 成本次优，仅调用 LLM 总结实体或关系，时间成本第二长，归因于耗时的实体链接过程。
    
*   **知识图谱** Token 消耗适中，需要 LLM 进行实体提取和三元组生成，但因三元组获取后知识图谱构建快速，达到最短耗时（DALK 最快）。
    
*   **丰富知识图谱** Token 消耗最多，因为它在标准知识图谱基础上通过LLM为实体和关系生成额外描述，导致时间成本增加。
    


### 2. 组织度


使用非孤立节点比例作为指标（树结构不适用此指标）。结果显示知识图谱表现最佳，其非孤立节点比例保持在约90%。丰富知识图谱表现次优；虽然引入了额外信息，但也不可避免地引入了更多噪声。段落图的非孤立节点比例最低，表明实体链接工具未能有效建立大多数实体对之间的边。


## （二）知识检索评估


![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/technology-popularization/knowledge-retrieval-process.jpg)

*   **索引时间：** GFM-RAG 索引时间最短；它不构建传统的向量数据库存储实体，而是在图构建阶段专门存储与问题对应的实体。在使用向量数据库的方法中，KGP、RAPTOR 和 DALK 因存储信息量少而成本较低；ToG、G-Retriever 和 LightRAG 成本适中，因为存储关系本身耗时；GraphRAG 因额外存储社区报告而进一步增加索引时间。HippoRAG 索引时间最长，归因于其额外构建实体<->关系和关系<->文本块映射。
    
*   **平均检索时间：** RAPTOR 速度最快，其树结构能快速定位信息。GFM-RAG 和 HippoRAG 紧随其后，分别利用 GNN 和 PageRank 算法进行检索。G-Retriever 采用带奖励收集斯坦纳森林算法（Prize Collecting Steiner Forest），LightRAG 依赖基于关系的检索，两者都引入了额外延迟。GraphRAG 需要利用社区信息检索，导致耗时较长。KGP、ToG 和 DALK 因检索时依赖调用 LLM 而产生显著时间成本。
    


## （三）生成准确率评估


![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/technology-popularization/generation-process.jpg)

*   鉴于 GPT-4o-mini 本身已具备较强的问答能力，并非所有 GraphRAG 方法都能有效提升其性能。
    
*   **性能下降：** DALK 和 G-Retriever 反而降低了 LLM 性能；它们过度依赖结构信息而牺牲了语义内容，在生成过程中引入了过多噪声，损害了 LLM 的判断准确性。
    
*   **小幅提升：** LightRAG、ToG 和 KGP 实现了小幅性能提升，表明其检索到的内容对生成任务提供了有限的帮助。
    
*   **显著提升：** 相比之下，GFM-RAG、GraphRAG 和 HippoRAG 通过有效整合图结构信息和文本块级语义显著提升了 LLM 性能：GFM-RAG 利用大规模预训练获得鲁棒的基础模型，GraphRAG 利用基于社区的信息优化检索，HippoRAG 通过 PageRank 算法提升检索效率。
    
*   **最佳方法：** 实验中表现最佳的方法是 RAPTOR，它通过迭代聚类构建树结构，这种设计与教材数据天然的分层组织结构高度契合，能够高效检索相关信息。
    
*   **超越传统 RAG：** 大多数 GraphRAG 方法优于 BM-25 和 TF-IDF 等传统 RAG 基线，突显了基于图的架构在提升生成准确率方面的效用。
    

## （四）推理能力评估


![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/technology-popularization/reasoning-ability.jpg)

*   与生成任务的高准确率相比，GPT-4o-mini 在推理性能（ R 和 AR 得分）上表现出显著下降。R 得分的下降表明 LLM 常常无法进行正确推理，而是在许多情况下通过猜测或模式匹配来选择答案。AR 得分的下降表明，即使 LLM 提供了正确答案，其推理过程也可能存在缺陷；或者它们可能生成了正确推理但选择了错误答案。
    
*   **显著提升：** 所有 GraphRAG 方法都显著增强了 LLM 的推理能力：通过不同的算法设计，这些方法不仅检索到与问题语义相关的语料，还识别出知识库中具有多跳依赖性的语料，为 LLM 的推理提供了证据支持。这使得 LLM 能够基于外部信息进行推理，而非仅依赖内部知识进行猜测。
    
*   **算法性能分布：** 在算法性能分布上，与生成任务类似：HippoRAG 和 RAPTOR 仍是表现最好的，这很直观，因为检索到有用信息本身就与实现正确推理相关。
    
*   **超越传统 RAG：** 大多数 GraphRAG 方法仍然优于传统 RAG 基线（TF-IDF, BM-25）。
    


## （五）主题特定生成准确率分析


鉴于我们的数据集跨越 16 个不同主题领域，我们对 GraphRAG 对 LLM 生成准确率的影响进行了细粒度分析。总体而言，GraphRAG 在大多数领域带来了一致的提升。然而，也发现了一些有趣的发现：

![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/technology-popularization/Generation-Accuracy-by-Topic..jpg)

*   **数学领域：** 所有 GraphRAG 方法都降低了 LLM 在数学题上的生成准确率。这是因为数学问题关键依赖于严格的符号操作和精确的推理链；模型必须在内部“计算”每个演绎步骤，而非依赖外部文本的关键词匹配。通过 GraphRAG 检索到的大多数文档是解释性或概念性的，其符号表示、公式布局和上下文结构常与问题要求不符，导致信息提取和转换过程中产生歧义或关键步骤丢失。
    
*   **伦理领域：** GraphRAG 和 LLM 本身在伦理题上的表现都平平。我们认为伦理问题从根本上涉及主观价值判断，其含义取决于道德权衡和社会规范的动态语境。LLM 通过统计学习捕捉的符号表示难以准确建模模糊的伦理概念，在推理上存在固有局限。
    
*   **稳健性：** 优秀的 GraphRAG 方法在大多数主题上显著提升了 LLM 的生成准确率，展现出稳健的性能，验证了其跨领域有效性。
    

  

**五、Observation**
=================

**🙋GraphRAG 能否提升所有问题类型的性能？**
-----------------------------

*   **单项选择问题准确率下降：** LLM 通过在大型语料库上的广泛训练内化了海量知识，使其在选择题任务中常能正确选择答案。然而，GraphRAG 基于检索的增强可能引入冗余或松散相关的信息，这些信息与问题语境并非精确匹配。此类检索噪声会干扰模型的决策能力，最终降低其在单项选择问题上的准确率。
    
*   **判断正误问题性能提升：** TF 问题需要对事实或逻辑陈述进行二元判断。LLM 可能对某些事实存在盲点或不完整的知识，导致错误答案。通过检索相关的事实证据，GraphRAG 帮助模型在回答前验证陈述。这些补充信息提高了模型在判断正误问题上的准确率。
    
*   **开放式问题性能提升：** 开放式问题允许广泛、详细的回答，这对于仅依赖内部知识的 LLM 来说可能具有挑战性。GraphRAG 通过提供来自外部语料库的额外上下文和事实来缓解这一挑战。检索到的信息丰富了模型的回答，提升了主题细节和表达能力，并通过将答案基于明确证据来减少幻觉。
    
*   **填空和多项选择问题的不同效果：** 填空问题需要精确的上下文理解以正确预测缺失词。GraphRAG 检索到的语料通常无法匹配确切的语境，引入噪声从而降低模型在填空问题上的表现。多项选择题需要从一组选项中选择多个正确答案，涉及对选项复杂组合的推理；如果 GraphRAG 的检索遗漏了相关答案选项或包含了无关细节，则可能混淆模型。因此，这些问题类型对检索精度要求很高；除非 GraphRAG 的检索非常精确，否则其收益可能有限。
    

**🙋GraphRAG 能否有效增强 LLM 的推理能力？**
--------------------------------

实验表明，GraphRAG 能有效增强 LLM 在各种问题类型上的推理能力，提高了在生成答案的同时生成正确推理依据的概率。

这归功于其高效的检索机制，不仅能为问题识别高度相关的语料，还能为 LLM 的推理过程提供有力的证据支持。特别是，现有基准缺乏对 GraphRAG 推理能力的系统性评估，而这在实际应用中至关重要。例如，在本文针对的大学级教育场景中，寻求专业知识的用户不仅期望正确答案，还期望清晰的推理依据以促进理解和知识获取。同样，在医疗场景中，患者需要清晰的用药依据和治疗建议，以确保决策的透明度。因此，有效的 GraphRAG 方法不仅应追求答案生成的高准确率，还应追求强大的推理和可解释性。

  

**六、结论**
========

本文提出了 GraphRAG-Bench，这是首个专为 GraphRAG 设计的领域特定基准。它包含一个跨越 16 个学科的数据集，通过多跳推理、复杂算法/编程任务、数学计算和多样化问题类型挑战现有方法，覆盖图构建、知识检索、生成和推理的全方位、多维评估，量化了结构化知识增强对 LLM 推理能力的提升。在九种前沿 GraphRAG 方法上进行的广泛实验，揭示了图集成在提升推理和生成性能方面的重要作用。


  

‍

  



GraphRAG 真的超越了 RAG 吗？GraphRAG 哪家强？GraphRAG 性能评估标准有哪些？

技术科普｜首个 GraphRAG-Bench 如何评估九大 GraphRAG 性能？

NebulaGraph 是一款开源的分布式数据库，擅长处理千亿节点万亿条边的超大数据集，为实时推荐、风险控制、知识图谱、数据治理等多个场景提供毫秒级查询延时的图数据库解决方案。

[NebulaGraph 开源五周年](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247510227&idx=1&sn=a0ac62523a169bc534e86cc9495acfad&scene=21#wechat_redirect)以来，一直在探索图的价值。

NebulaGraph GenAI Team Leader 古思为提出了将图数据库与 RAG 结合的想法，并于 2023 年 8 月，向 LlamaIndex 提了第一个PR，将 KG-RAG 转变为 GraphRAG.

GraphRAG 不依赖于向量数据库，而是利用图数据库来存储和检索信息。它通过大型语言模型抽取文档中的主要关系和实体，并将它们转换为图结构存储在图数据库中。这种方法不仅提高了检索的强度，还能够更好地处理全局上下文搜索和领域知识集成的问题。

更多 GenAI Team 工作动态及 NebulaGraph AI 应用平台相关资讯请访问⬇️

https://www.nebula-graph.com.cn/ai-application-platform


![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/AdventureX-NebulaGraph/AdventureX-NebulaGraph-AI.jpg)

作为 GraphRAG 的提出者，我们希望以不一样的方式见到更多对 Graph+AI 拥有无限创造力的小伙伴，因此与 AdventureX 举办了本次 Graph + AI BuilderUp！



# 什么是 BuilderUp？

BuilderUp 是 AdventureX 对“线下社区活动”的全新想象。

它名字来源于 MeetUp，但它却不只是简单的“线下聚会”活动，而是一场只属于 Builders 的运动——为那些真正在创造、在打破、在推动时代前进的人而设。

绝大部分社区活动的调性，或者说是 Vibe、Taste 不太对，而调性的缺失则会对整个活动的参与人群、组织形式等产生影响。这样的活动早已无法激发属于这个时代的创造能量。它们就像是 Adventurex 出现之前的黑客松。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/AdventureX-NebulaGraph/AdventureX-NebulaGraph-BuildUp.jpg)


于是，BuilderUp 出现了。如同我们用 AdventureX 革命了黑客松的呈现形式一样，BuilderUp 将带来线下社区活动的新范式。



# 我们玩些什么？

本场活动没有“嘉宾”，每个人都是主角，每个人都将分享一些东西。

**签到**
没有签到，不会准时开始，当大家差不多到齐时，BuilderUp 自然开始。

**自我介绍**
围成扇形坐下，依次开始自我介绍，请用有意思的故事或者工作让大家认识你，而不是简单地介绍你是谁、职业是什么。

**Mini Talk**
主持人随机邀请 2-3 位小伙伴上台进行分享，无需准备 PPT，真诚表达即可。

**自由交流**
现场将播放音乐，我们进入自由交流时间，优先以''Graph+AI''打开话题，当然也可以天马行空聊任何事情，比如今天出门时遇到一只非常可爱的狸花猫。

**结束才是真正的“开始”**
BuilderUp 结束后，志同道合的小伙伴们可能会去到别的地方继续交流，更深的链接由此展开。



# 如何报名？

为确保这是一场富有创造力的 BuilderUp, 请有意向的小伙伴填写报名问卷，NebulaGraph 将根据问卷确定参与者名单。

如果你是 AdventureX 2025 录取者，可在问卷中说明，直接参与本次 BuilderUp.

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/AdventureX-NebulaGraph/AdventureX-NebulaGraph-BuildUp-1.jpg)

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

6.28 北京站 nMeetup 🔥⬇️

[北京 nMeetup ｜NebulaGraph 图数据库的实践与应用（转发有奖）](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516729&idx=1&sn=efe9aca67440497bb73e2957aaddda9f&scene=21#wechat_redirect)

⚠️活动地址更改为：北京市海淀区中关村创业大街 6 号楼 B1 层

作为 GraphRAG 的提出者，我们希望以不一样的方式见到更多对 Graph+AI 拥有无限创造力的小伙伴，因此与 AdventureX 举办了本次 Graph + AI BuilderUp！

AdventureX x NebulaGraph｜Graph + AI BuilderUp 杭州站报名


> 导读：「分布式锁」技术科普系列，由 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 在携程集团的应用与实践