> 本文整理自 NebulaGraph Engineer Hao Wen 在 AI Memory Forum 2025 上的演讲。 

今天我们不谈基础的图数据库概念与应用场景，而是聚焦于一个更前沿的融合领域——基于图的 RAG 平台。

在大型语言模型席卷全球的当下，企业面临的核心挑战已从如何搭建一个大模型转变为如何安全、高效、低成本地使用大模型处理私有知识。

# 一、当前大模型落地的现实路径

面对私有化部署和知识更新问题，目前主要有两种路径：微调与纯接口调用。

* 微调：成本高昂、流程复杂，文档的每次更新都可能触发重新训练

* 纯接口调用：无法触及企业内部知识，无法根治模型的幻觉问题。

在这两种方案之间，RAG（检索增强生成）脱颖而出，成为平衡成本、安全性与可行性的主流范式。

RAG 的核心逻辑清晰：为内部知识建立索引，在提问时先进行检索，再将精准的上下文喂给大模型，从而生成可靠答案。

![](https://pica.zhimg.com/80/v2-8ea26badc187f0e5bdd365856cee6026_1440w.jpg?source=ccfced1a)


然而，当人们谈及 RAG，脑海中首先浮现的往往是向量数据库与嵌入模型。但这条路，真的足够平坦吗？

# 二、RAG 四大困境

深入实践后，我们发现传统的向量 RAG 存在几个结构性问题。

![](https://pica.zhimg.com/80/v2-94567725052180ffb96509bf2d0caa26_1440w.jpg?source=ccfced1a)

## （一）细粒度检索不足

![](https://pic1.zhimg.com/80/v2-572f270094719ca8907a1b075cb39d19_1440w.jpg?source=ccfced1a)

以《乔布斯传》为例，提问“乔布斯与 Apple 有哪些重要事迹”时，Apple 是决定检索准确性的核心实体。当相关内容集中于以 Apple 为主题的 chunk 中时，向量检索较容易命中。

但若 Apple 相关信息仅在讲述乔布斯个人经历等其他主题的 chunk 中零散出现，其语义权重会被整体主题稀释，导致关键事实难以被准确召回，暴露出向量 RAG 在细粒度检索上的局限性。

## （二）关系缺失

文档之间天然存在引用、衍生、对立等复杂关系，向量数据库将文档切分为孤立的片段后，数据的关联随之减弱。

## （三）语义鸿沟

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

语义相似度 ≠ 上下文相关性 。举个相似但不相关的例子，保温杯与保温大棚，两者 token 在很大比例上表达共同的语义：“保温”。但在一些场景下，想要了解保温杯却召回了保温大棚的信息。

RAG 在索引阶段即使设置了比较高置信度，也很可能因为其相似性而得到不相关的信息。

## （四）全局推理乏力

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


"所有文档的核心观点是什么？"、"请总结出最重要的五个发现"。这类需要跨文档综合分析、提炼的全局性、社区级问题，恰恰是向量检索的短板。

# 三、图的破局：

从孤立片段到关联网络

如何破局？答案是图数据库。微软研究院一篇重要论文也论证了图数据库在增强 RAG 能力方面的价值。

事实上，NebulaGraph 在微软之前就率先提出了 GraphRAG，而且微软在论文中也引用了我们的 GraphRAG 相关工作。

NebulaGraph 是分布式开源图数据库，愿景是成为全球第一的图数据库厂商。目前，在 DB-Engines 的图数据库排行榜上，我们排名全球第二。

NebulaGraph 主要面向大规模、高性能的应用场景，支持千亿点、万亿边的超大规模数据集。同时，我们也是最早一批参与国际标准图查询语言 ISO-GQL 制定标准，并实现全球首个全面支持 ISO-GQL 的图数据库产品。

现在说回图数据库如何解决 RAG 所面临的挑战。

## （一）解决文档切分难题

在向量数据库中，第一步通常是将文档切分成 chunk，然后生成向量。随之而来的问题是：chunk 多大才合适？

* 如果 chunk 太小，可能会切断语义，甚至产生与原意相反的含义；

* 如果 chunk 太大，真正有价值的信息只占其中一小部分，导致相似度得分反而很低。

![](https://picx.zhimg.com/80/v2-8b972133532bc951d7eaba5a3b72694c_1440w.jpg?source=ccfced1a)

在图模型中，文档、章节、段落可以作为具有丰富属性的节点存在，并通过边明确表达其间的层级、引用关系，语义被结构性地保留下来。

## （二）重建上下文关联

一个多级部门文档体系，比如一级部门纲领、二级部门细则、三级部门报告，彼此之间存在引用关系。

* 在向量数据库中，这些文档被切成 chunk 后是“平权”的，无法保留层级、来源和引用关系。

* 在图数据库中，我们可以清晰地建模"发布"、"引用"、"归属"等关系，形成一个可追溯、可解释的知识网络。

## （三）解锁复杂推理能力

![](https://picx.zhimg.com/80/v2-636b0c1b9e39469714c4d35ebf2bb44a_1440w.jpg?source=ccfced1a)

对于"文档 A 与文档 C 有何关联？"这样的问题，GraphRAG 可以通过子图搜索、路径查询轻松找出连接路径。

对于"总结核心要点"，则可以利用社区发现、中心性分析等图算法，识别出网络中最关键、最聚合的信息群。

# 四、超越 GraphRAG：Fusion GraphRAG 的诞生

当然，GraphRAG 自身也面临挑战：

* 索引构建成本高、耗时长；

* 不擅长多模态数据（而向量可统一表示文本、图片、音频等）；

* 面对数据版本冲突时，可能会无意中合并冲突信息，生成错误答案。

为此，NebulaGraph 提出了原创的 Fusion GraphRAG 架构。

![](https://picx.zhimg.com/80/v2-51aa21d9b72bb243535c7322c5cb983c_1440w.jpg?source=ccfced1a)


![](https://pica.zhimg.com/80/v2-243aa8b5a965714fc5e5190bd2e65b31_1440w.jpg?source=ccfced1a)


Fusion GraphRAG 在知识图谱之上，创新地增加了一层文档元数据与结构索引层。这一设计带来了显著的效率提升：

* 相比 GraphRAG，索引构建速度提升约 5 倍；

* 在与微软 GraphRAG 的对比中，索引阶段更是快了近 20 倍，同时问答准确率更高。

这一架构构建在 NebulaGraph 原生分布式图数据库之上，实现了图、向量、全文三索引融合。

* 图索引：负责处理实体、关系与复杂路径查询。

* 向量索引：快速捕捉语义相似的片段。

* 全文索引：支持精确的关键词匹配。

三种索引各司其职，又协同工作，再结合多样的图算法，共同支撑起强大的检索与推理引擎。

# 五、开箱即用的图增强 AI 平台

![](https://pic1.zhimg.com/80/v2-57a50ffd0a16a4fcd8e20d6ae29e2e9c_1440w.jpg?source=ccfced1a)

基于 Fusion GraphRAG，我们构建了完整的 AI 应用开发生态：

* Nebula AI Application SDK：为开发者提供灵活调用的工具包。

* Nebula AI Application Platform：零代码开箱即用的端到端平台，用户只需选择知识库，即可创建专属 AI 应用。

* 云服务：提供弹性可扩展的云上服务。

开发层面，用户可以零代码创建 AI 应用，选择使用的知识集。问答层面，体验如 ChatGPT 般自然流畅，并且因为基于图索引进行检索，因此整个过程是可视化、可解释、可审计的，你可以清晰地看到答案是如何一步步从知识网络中推理生成的。

在 Benchmark 测试中，我们平台的问答准确率达到了 0.81，在优化场景下可达 95%，显著优于当前领先的开源方案。

# 六、结语

大模型开启了人机交互的新篇章，但其在企业级场景中的真正价值释放，依赖于对私有知识的安全、精准、深度利用。当传统向量检索在复杂关联与深层推理面前力有不逮时，图数据库以其固有的关系表达能力，为 RAG 提供了关键的上下文、结构和逻辑。

而 NebulaGraph 的 Fusion GraphRAG，正致力于将图的深度、向量的广度与全文的精度融为一体，为企业构建下一代可信、可解释、具备复杂推理能力的 AI 应用，提供坚实的数据基础架构。





Fusion GraphRAG：超越 GraphRAG 的多模态企业级 AI 问答

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

> 本文基于演讲内容与 PPT 材料整理，部分数据与案例已脱敏，仅供参考交流。
 PPT 下载： https://discuss.nebula-graph.com.cn/t/topic/17404 

很高兴在这个夜晚与大家在线上相遇。我是来自 NebulaGraph Product VP 杨哲超。今天，我想与各位分享在AI 与图数据库交叉领域的一些思考与实践。

图数据库或许对很多开发者来说仍是一个相对垂直和小众的产品，但实际上，它与人工智能的关系极为紧密。在大模型兴起之前，知识图谱已是 AI 体系中不可或缺的技术组成部分，而图数据库，正是知识图谱的最佳底座，专注于解决多元异构数据的融合、分析与决策问题。

在数据库权威排名 DB-Engines 上，[NebulaGraph](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515915&idx=1&sn=4f53647870a1c02566c17504fac516fc&scene=21#wechat_redirect) 在全球图数据库类别中排名第二，在国内则位居榜首。我们不仅支持超大规模图数据、具备高性能与低构建成本等特性，更在 AI 时代持续探索图与智能的深度融合。

# 一、AI 的期望与现实：为何大模型难以深入产业？

当前 AI 行业面临一个明显矛盾：一方面，政策与产业界对大模型寄予厚望。从国家“十五五”规划对人工智能的全方位赋能要求，到高盛预测未来数年在生成式 AI 上近 1 万亿美元的投入，无不显示各界对 AI 推动生产效率提升的期待。

然而另一方面，大模型在生产领域的规模化商业回报尚未显现。据 Gartner 预测，超过 30% 的生成式 AI 项目将在概念验证阶段后被放弃，原因涉及数据质量、风险控制、成本与业务价值不明确等。MIT 的研究进一步指出，最终仅有约 5% 的 AI 项目能进入生产环境并实现可衡量的业务价值。

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

我们认为，造成这一割裂的核心原因有两个：

**1. 模型幻觉问题**：本质是基于概率的预测模型，其设计目标并非严格遵循事实，导致在高精度、高可靠性要求的场景中，输出结果难以信赖。

**2. 数据孤岛问题**：即使是最强大的通用大模型，也难以接触到各行业内部的专有数据，例如政务内网、企业业务系统等，导致模型在垂直领域中“看不见”关键信息，难以触及生产核心。

## 二、GraphRAG：

从检索答案到核查事实的范式升级

最近 Google 推出的NotebookLM之所以受欢迎，正是因为它通过引入外部知识源，显著降低了模型幻觉。这背后的关键机制正是 RAG.

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

RAG 的本质，是让大模型从记忆里找答案转变为到事实中去核查。而目前常见的 RAG 索引方式主要有三种：全文索引、向量索引和图索引。

**1. 全文索引**：基于关键词匹配，略显生硬，依赖倒排索引等技术。

**2. 向量索引**：更接近语义检索，能够理解内容含义，适合推荐、相似性查询等场景。

**3. 图索引**：核心是找关系，能够保留数据中丰富的关联信息，避免信息被切割丢失。

相比前两者，GraphRAG 可视为传统 RAG 的革命性升级。它将知识图谱与图技术深度整合到大模型架构中，显著提升了上下文关联性、推理深度与结果可解释性。

# 三、GraphRAG 的挑战与 NebulaGraph 的破局之路

尽管 GraphRAG 优势明显，但其应用仍面临两大门槛，这让很多想尝试的开发者望而却步：

* **技术门槛高**：涉及命名实体识别、关系抽取、社区划分等多项 NLP 技术，需要大量标注数据与模型调优。

* **使用成本高**：构建与使用成本高出向量索引两个数量级，且依赖大量 GPU 集群进行推理。

![](https://picx.zhimg.com/80/v2-20441f11d4a69013f51c3a76deb5f1b6_1440w.jpg?source=ccfced1a)

**为了不让 GraphRAG 沦为 PPT 里的摆设，NebulaGraph 核心做了两件事**：

****1. 降低技术门槛**：让业务人员也能驾驭图**

我们不希望 GraphRAG 是一个无法干预的黑盒。通过提供可解释、可干预的工具，业务人员可以根据行业理解在图谱中直接插入规则。这种人工干预+模型概率的结合，才能保障产品在生产环境里的可靠性，真正实现：

* 透明可控：可视化流程 + 全链路审计，节点与关系一目了然；

* 灵活定制：支持在节点与边上插入业务规则，无需重新训练即可快速迭代；

* 高效协作：拖拽式无代码配置，降低操作与调优难度。

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


**2. 降低使用成本：打造端到端自动化工具链**

我们将 GraphRAG 从科研项目转变为标准产品，大幅压缩实施周期与成本：

* 传统流程需经历：数据清洗 → 分块 → 实体抽取 → 关系抽取 → 社区发现 → 摘要生成 → 图入库 → 接口封装，全程约需 2–4 周 ；

* NebulaGraph 自动化方案：

* 通过大模型自动识别数据领域，覆盖约65%的高频行业场景；

* 高集成封装，开箱即用，数小时内即可完成图谱构建，初始 F1 值可超0.85；

* 遵循第一性原理优化，建索引效率较微软 GraphRAG 提升约两个数量级。

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

# 四、实战案例：

基于图智能的运维根因定位

分享一个我们最近在头部运营商落地的真实案例。在处理海量运维工单时，传统的做法是靠老专家的经验，在成千上万行日志里“捞”根因，不仅累，还容易漏。

NebulaGraph 的解决方案是，把工单按时间线来“连线成图”。 通过将每一个工单子图融合成一张全局知识大图，再利用 PageRank 等算法自动计算节点的权重。最终的效果非常惊艳：

* 定位准确率提升至85%；

* 平均定位时间从 60 分钟降至5 分钟，效率提升12 倍。

该方法已申请发明专利，并适用于金融、电力、制造等所有具备时序日志与告警体系的场景。

![](https://pic1.zhimg.com/80/v2-2696834de7d75a315b0f32fbb7643933_1440w.jpg?source=ccfced1a)

（感兴趣的小伙伴，可以借鉴类似案例，如 BOSS 直聘 20 秒根因定位）

[![](https://picx.zhimg.com/80/v2-4a11cee4f33f8b9e4bc0543936dbb68f_1440w.jpg?source=ccfced1a)]()

# 五、趋势展望：

Graph + AI 推动大模型走向专业决策

站在现在看未来，我们认为 Graph + AI 会有两个显著的信号：

**1. 从孤岛走向知识中枢**：现在的 AI 很多是单点应用（比如一个简单的聊天机器人）。未来，企业会更倾向于把自有数据连接成一张大图，构建真正的企业大脑，支持更复杂的业务决策。

**2. 从事后分析走向事前预测**：现在的 RAG 大多是静态的检索，未来它会更具动态性。大模型将不只是告诉你发生了什么，而是能参与到事中的干预，甚至预测可能发生的风险。

# 六、愿景：

共建开放、智能的图数据生态

作为国内领先的图数据库厂商，NebulaGraph 将持续推进图与 AI 的融合创新：

* 推动GQL 标准化与GraphRAG 架构规范化，降低行业使用门槛；

* 与高校、研究机构合作，培育“图 + AI”复合型人才；

* 开放产业案例库，分享跨行业实践，加速技术落地；

* 积极集成 Memory Zero、Memory Machine 等 AI 组件，构建更开放的图智能生态。

我们相信，图 + AI 将成为企业数字化转型的核心引擎，但技术落地不是一家公司能完成的，希望未来能与更多开发者一起，赋能千行百业实现真正意义上的智能升级。

图数据库与AI 结合，让大模型从智能问答到专业决策

从智能问答到专业决策：Graph + AI 如何驱动大模型走进产业核心

2025 年，你和 NebulaGraph 一起肝了哪些项目？有没有哪篇文章在你百思不解时，给了你灵感？

星云仔根据社区的阅读热度和专业深度，盘出了这份「2025 NebulaGraph 高光文章年鉴」。快来看看，这些过去一年被反复转发和讨论的宝藏，你错过了哪一篇？

> 星云仔温馨提示：点击图片，直接跳转文章原文

# 一、图数据库选型

什么场景选择图数据库是最佳解决方案？本文以客户-经理-助理的典型关系为例，揭示关系型数据库依赖外键隐式表达关系的局限，并展示以 NebulaGraph 为代表的图数据库，在复杂关系场景的显著优势，用最通俗易懂的语言让你理解：当数据关系复杂、变化频繁且需深度探索时，图数据库是不可替代的解决方案。

[![](https://pica.zhimg.com/80/v2-9120da470584b8c54c9f82baf023eef4_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HOFkaGmjFPHSiX3Aqctr1K3QNcAfT33MF3Bxs8Za&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515828%26idx%3D1%26sn%3Deb22a1dd1b4f5ca4c1cf45dd20f6a543%26scene%3D21#wechat_redirect)


如何选择一款适合业务需求的图数据库？在 DB-Engines 国内外排名第一的 NebulaGraph 与 Neo4j 选型对比中，核心差异在于架构与定位。Neo4j 的 Cypher 语言成熟、生态完善，适合中小规模深度图分析。而 NebulaGraph 采用原生分布式架构，在十亿级边数据下查询性能优势显著，并全面支持信创环境，更适合需要水平扩展、高性能及国产化替代的大规模实时场景。

[![](https://picx.zhimg.com/80/v2-bc32a5fc9705b608673036dfde8ea1fb_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HP5kaGmjdqPxdf-4MDJpvB8kJkM0qkv92vpeSsHR&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247516042%26idx%3D1%26sn%3D10ba45d8f96921c65c2918cd68ea6425%26scene%3D21#wechat_redirect)


为何选择 NebulaGraph？作为全球数据库领域的“奥斯卡奖”，DB-Engines 排名是衡量数据库流行度的重要指标。2025 年 9 月，NebulaGraph 在 DB-Engines Graph 类别中排名第二，不仅证明了 NebulaGraph 在全球开发者社区和市场需求中的受欢迎程度，更体现了中国基础软件在国际舞台上的崛起。

[![](https://picx.zhimg.com/80/v2-d97ddda851dbd91289436bb63199c049_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515915&idx=1&sn=4f53647870a1c02566c17504fac516fc&scene=21&poc_token=HCRlaGmjsfVbt-qIaQ2jQoeisjTKKt1GZ--7ttd4)


# 二、AI+知识图谱

在 DeepSeek 问世之初，尝试将其与 NebulaGraph 结合，从零构建农业知识图谱，验证 AI 在知识结构化方面的强大能力。

首先，DeepSeek 能够从单篇文章中提取实体与关系，生成规范的 nGQL 脚本，快速构建基础图谱。其次，面对多源信息，AI 可自动融合新知识，动态扩展图谱结构，并支持属性与关系的增量更新。最后，即使仅输入主题描述，DeepSeek 也能“无中生有”生成符合逻辑的图谱框架，为冷启动场景提供可行路径。

[![](https://picx.zhimg.com/80/v2-a694f462ffe3d75f4686d73997ec3ca5_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515784&idx=1&sn=d195852253cc8a23b0ce879f37c94034&scene=21&poc_token=HKyBaGmjmLry6iivplDU1carUUe44EE3nj2i6-JY)


用 DeepSeek + NebulaGraph 构建知识图谱的类似实践，还有以下两篇～

[用 NebulaGraph + DeepSeek 解锁元宵节文化知识图谱，你知道几个？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515785&idx=1&sn=fdfbd45d83a9bf98a9623c237fa104ef&scene=21#wechat_redirect)

[NebulaGraph + DeepSeek 轻松看懂《哪吒2》人物关系](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515788&idx=1&sn=deb566e6826106f6d454bd822c06f157&scene=21#wechat_redirect)

‍‍‍

# 三、GraphRAG

在高级 RAG 技术演进中，由 NebulaGraph 提出并落地的 GraphRAG 成为解决传统检索框架知识稀释、关联丢失与宏观分析难题的重要路径。2025 年，NebulaGraph 进一步提出 Fusion GraphRAG 方案，系统融合文档层级、章节结构与图谱语义，在统一图存储中实现多层级、多模态的知识索引与检索。

Fusion GraphRAG 不仅支持基于元知识层的精准召回，还可通过 Chain of Exploration 在图谱中自主探索，完成从全局摘要到局部深查的复杂任务。

基于 Fusion GraphRAG，NebulaGraph 进一步推出低门槛的 AI 应用平台，支持企业以知识篮子方式组织文档，并通过对话快速构建智能应用。

[![](https://pic1.zhimg.com/80/v2-63ffbc9cb383f7bb2b0b6804d88c3816_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HM6BaGmjRNDMi3KH04B_UyvN3-mYKOlrYfmF2Io1&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515791%26idx%3D1%26sn%3D70f19b1a2b329fcfe3f4c8b72dd73955%26scene%3D21#wechat_redirect)

针对生物医学领域知识复杂、AI 易产生幻觉的痛点，国外开发者 Diya Mandot 构建了专业的生物医学问答系统 BioGraphRAG. 该项目以 NebulaGraph 作为核心图数据库，高效存储并管理了超过千万实体、数千万关系的 BioKG 数据集，并利用多进程优化，将数据导入时间从 33 小时大幅缩短至 3 小时。

[![](https://picx.zhimg.com/80/v2-e12ae36d75c6816762bd2b998b69596d_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HOSBaGmjxzB_ij0xC8LrnTgl0MX76JPDfSSvEZUZ&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515825%26idx%3D1%26sn%3D966b393b631c5409637052d3a725184b%26scene%3D21#wechat_redirect)


如何提升 RAG 的效果？如何把 NebulaGraph 和大模型相结合？这里有系列教程，手把手教大家从 0 到 1 搭建一款垂直领域 AI 应用。

[星云实验室 part 1｜用知识图谱+GraphRAG,构建垂直领域 AI 应用](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515815&idx=1&sn=a22215ce45b2ff9d45f852046310b378&scene=21#wechat_redirect)

[星云实验室 part 2｜用知识图谱+GraphRAG,构建垂直领域 AI 应用](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515817&idx=1&sn=76729810a53419a3848289fbdc24a90b&scene=21#wechat_redirect)

[星云实验室 part 3｜构建知识问答聊天引擎与前端交互页面](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515819&idx=1&sn=d4e7a553a10e698bc03c6267426174f1&scene=21#wechat_redirect)

# 四、用户案例‍‍‍‍

告警响起，面对成百上千个微服务调用，问题究竟出在哪层网络、哪个应用、哪台主机？这就是 BOSS 直聘运维团队每天要面对的挑战。

直到他们用 NebulaGraph 构建起一张实时的全景图谱，所有服务、主机、中间件都变为点和边，调用关系、性能指标一目了然。当故障再次发生时，借助 NebulaGraph 的高性能图查询与图算法，仅用 20 秒就能实现根因定位，把平均故障修复时间压缩到分钟级别，让运维团队从此告别连猜带蒙，真正实现智能运维的质变。

[![](https://picx.zhimg.com/80/v2-830615d0bcadf0b622a5886ff7c41ae4_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HP6BaGmjiXsF7hXGI7hzPnw39PoojuqqXl7udgEg&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515831%26idx%3D1%26sn%3D7a5034daaf9414cb20452af1dadfa272%26scene%3D21#wechat_redirect)


面对海量且复杂的业务关系，携程选择将 NebulaGraph 深度集成到其基础设施中，并巧妙构建了一套覆盖单机房、三中心与跨域多活的弹性部署策略。通过客户端的定制化改造，他们成功将跨域查询的网络损耗降低了 70%，并实现了QPS 跃升23%、平均响应稳定在毫秒级的出色表现。

这一实践不仅证明了 NebulaGraph 在千亿级超大规模场景下的强大性能，更体现了携程工程团队如何通过精细化的架构设计与调优，让图技术真正服务于核心业务。

[![image|690x293](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/xiechen.webp)](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515805&idx=1&sn=2880a5d7dd0608f55a2b834687d64dac&scene=21&poc_token=HD2CaGmjeExMFMmFrg-va4ygfQ2LqyyCUaAOiFVf)


在追求 GraphRAG 国产化落地过程中，中科数睿团队系统探索了包括 NebulaGraph、TuGraph 在内的多款国产图数据库，并历经了从微软开源方案、DB-GPT 到 KAG 等多种技术路径的迭代。基于 DeepSeek 大模型微调与诱导生成，团队最终创新性地构建了流式解析、分层存储与动态规划相结合的混合架构。该方案有效利用 NebulaGraph 处理结构化关系，并结合占位符回填机制，显著提升了专业领域问答的准确性与可解释性，为 GraphRAG 国产化落地提供了宝贵的一手经验。

[![](https://picx.zhimg.com/80/v2-82bda69d7ed5faea8c19674a5356b236_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HFSCaGmjSYlCm9pt-P-jtNUX13llK-PImVyj7WSQ&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515833%26idx%3D1%26sn%3D32a8665844ec6973b26ebb1abbfca03b%26scene%3D21#wechat_redirect)


# 五、技术科普

内存调试犹如大海捞针，尤其在复杂的 C/C++ 程序中，本文介绍的 Debug 神器 Core Analyzer 能够深入扫描堆内存，支持多种内存管理器，提供堆概览、泄漏检测、引用链追踪等一系列强大命令，极大提升内存问题排查的系统性与效率。它特别适用于并发场景下难以复现的疑难问题，是对 ASAN 等传统工具的重要补充。

[![](https://picx.zhimg.com/80/v2-ec3f4ff155da466d5002ed4b05fd7d2d_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HGOCaGmjmDaKj9nsYd3RwU_qZc4Zt5undEv0XLcQ&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzE5ODg1MDA1NQ%3D%3D%26mid%3D2247515811%26idx%3D1%26sn%3D42e6230d83a1a9570baf2496f048810e%26scene%3D21#wechat_redirect)


NebulaGraph 存储负责人@四王，回顾了 Redis 作者与 DDIA 作者围绕 Redlock 安全性的经典辩论，深刻揭示了分布式锁在时钟漂移、进程暂停等场景下的共性问题，其本质在于实现分布式一致性共识。对分布式锁的技术讨论充分体现了 NebulaGraph 团队对分布式系统核心问题的持续关注与研究深度，也为大家理解 NebulaGraph 的分布式架构实践提供了理论参照。

[![](https://picx.zhimg.com/80/v2-cedbf35a7506295f112a7284d8770423_1440w.jpg?source=ccfced1a)](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515816&idx=1&sn=f1f509474e7e887aac6d8ad2a56de769&scene=21&poc_token=HHaCaGmjfQZtHVry1V_bTb267PJS7RtgWcPy5Jmt)

# 六、Ending

回顾 2025，这些文章不仅记录了一场场技术的探索与实践，更映射出图数据库走向核心基础设施的清晰轨迹。无论是与 AI 的深度融合，还是在千亿级场景中的稳定性锤炼，NebulaGraph 与社区开发者共同交出了一份扎实的答卷。

感谢每一位读者的关注与阅读。技术的价值，在于被理解、被应用、被改进。希望这份年度盘点能成为你新一年探索路上的得力助手。




2025 年值得一读的图数据库文章

盘点 2025 年值得一读的图数据库文章～

12 月 22 日晚，快手直播遭遇大规模黑产攻击。

**超过 1.7 万个僵尸账号同时开播，海量违规内容绕过审核系统，露骨画面、擦边直播及诱导转账的“密码房福利”层出不穷**。多名网友描述"点开直播全是黄色内容"，甚至调侃“十个直播七个在放片”，部分直播间观众达数十万人。**用户举报按钮形同虚设，即便违规内容下架，新违规账号却持续涌现**。

最终迫使快手在 2 小时后，采取全平台截断直播的极端措施终止这场充斥淫秽与血腥的 P0 级事故。12 月 23 日快手股价盘中一度下探超 5.7%，较前一交易日蒸发约 164 亿港元。

这一夜，被不少从业者称为快手的“至暗时刻”。

但更值得警惕的是：

这并非某一家平台的偶发事故，而是整个行业风控体系的一次系统性失效暴露。

风控安全，不进则退。在 AI 驱动的自动化攻击面前，依赖 IP 黑名单、静态规则、预计算指标、事后审核的传统风控体系，已经难以支撑现代互联网业务的安全底座。

# 一、黑产击溃传统风控范式

快手 12.22 直播事故，真正击穿的，不是审核能力，而是风控范式。

从公开信息来看，快手并非没有健全的审核机制与风控体系，而是风控系统在黑产攻击方式升级后力不从心。

传统平台风控体系，大多建立在以下逻辑之上：

-   将账号、设备、IP、行为等关联指标提前计算
    
-   将结果写入 Redis / ClickHouse
    
-   通过规则引擎 \+ 阈值判断做风险决策
    ![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/traditional-risk-control.webp)

这套“预计算 \+ 静态规则”的体系，在过去多年行之有效，但在黑产迈入自动化攻击后便暴露出致命短板。

## 1\. 关联关系是“活的”，而预计算是“死的”

黑产并非单账号违规，而是：

-   多账号
    
-   多设备
    
-   多 IP
    
-   实时变换组合
    
-   同步协同攻击
    
关联网络在分钟级甚至秒级重构，而 T+1 或分钟级预计算指标天然滞后。

## 2\. 单点看似正常，整体却是异常

在传统风控视角下：

-   每个账号行为“合规”
    
-   每个 IP 访问“正常”
    
-   每次开播“合法”
    
真正的风险隐藏在多跳关系与群体结构中，而不是任何一个孤立指标。

## 3\. 高并发场景下，规则系统被压垮

当 1.7 万账号同时触发检测时：

-   AI 识别模型排队
    
-   人工复核失效
    
-   规则系统被放大流量拖垮
    

最终只能通过“全量截断”这种业务级熔断止血。

这场事故揭示了一个残酷现实：黑产的攻击是动态、协同、结构化的，而传统风控系统仍停留在静态、割裂、事后响应的阶段。

# 二、风控的本质在于“关系”

无论是直播黑产、支付欺诈，还是稳定币洗钱，本质都不是某个行为异常，而是：一张不断变化的关系网络，在协同掩盖真实意图。

-   一个设备控制上百账号
    
-   多个地址将资金归集至同一黑洞
    
-   多个看似无关的行为，构成完整攻击链路
    

这类问题，天然属于图问题。而这，正是传统预计算风控体系无法解决的核心原因。

在传统风控系统中，引入图数据库后，风险被可视化地展示为图谱。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/cluster-graph.webp)

NebulaGraph x 奇富科技（原 360 数科）群体关系图

上图是奇富科技生产环境的一个图，不同颜色的点分别表示不同的意义，红色是风险点，黄色是疑似风险，灰色是普通用户。

# 三、NebulaGraph 的实时图风控

## 1\. NebulaGraph

NebulaGraph 是一款开源分布式图数据库，擅长处理千亿节点万亿条边的超大数据集，同时保持毫秒级查询延时的图数据库解决方案。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/test.webp)

在百亿级数据量下的测试中：

-   传统关系型数据库：4 度关联查询，154 秒
    
-   NebulaGraph：4 度关联查询，0.14 秒
    

性能提升 1000 倍以上，这正是实时风控在高并发场景下的基础能力。

目前，NebulaGraph 已在以下场景中落地：

-   金融反欺诈与反洗钱
    
-   Web3 合规与资金追踪
    
-   交易平台黑产识别
    
-   实时风险图谱构建
    

NebulaGraph 的用户包括 Airwallex、众安保险、BlockSec、得物、携程集团等，构建了从千亿节点到万亿关系的实时风控图系统。

## 2.实时动态风控体系
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/risk-control-nebula.webp)

以 NebulaGraph 为代表的实时图风控体系，并不是在优化规则，而是在重构风控的底层认知方式。

**（1）不再预计算关系，而是实时构图**

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/dynamic-analysis.webp)

-   用户、账号、设备、IP、交易、行为
    
-   实时写入图中
    
-   关系随业务发生即时变化
    

风控系统不再依赖算好的结果，而是直接读取真实世界的当前关系状态。

**（2） 多跳穿透，识别群体型风险**
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/graph-algorithm.webp)

通过图查询和图算法，可以在毫秒级完成：

-   N 度关联穿透
    
-   账号–设备–IP–账号的闭环识别
    
-   团伙结构、控制中心、扩散路径识别
    

从「看单点」升级为「看结构」。

**（3）实时规则 + 图算法双引擎**

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/kuaishou-risk-control/graph-algorithm-2.webp)

-   实时规则：
    
-   “5 分钟内同一设备登录 10+ 账号”
    
-   “同一 IP 批量开播”
    
-   图算法：
    
-   社区发现
    
-   中心性分析
    
-   异常子图识别
    

规则负责即时拦截，图算法负责结构洞察。

**（4）在快手中引入图数据库**

如果在快手的场景中，引入实时图风控会发生什么？

在类似直播平台的业务中，实时图风控可以前置到多个关键入口：

-   注册
    
-   登录
    
-   开播
    
-   内容发布
    

当黑产设备开始批量注册或登录时：

-   关联关系已在图中显现
    
-   风险结构在规模化前被识别
    
-   攻击在“发起之前”即被阻断
    

这意味着：

-   审核系统不再被洪水冲垮
    
-   业务无需通过全量截断自伤止血
    
-   风控从被动救火转为主动拦截
    
    # 四、结语
    

这次事故，并不是开始，也不会是结束。随着 AI 攻击工具、自动化脚本、Web3 与跨境业务的普及，黑产只会更加动态、隐蔽、系统化。

企业必须重新认知风控：

-   风控不是一套产品，而是一种能力
    
-   防线不是静态规则，而是动态关系网络
    

只有具备实时构图、动态感知、结构洞察能力的图风控体系，才能在这场长期对抗中掌握主动权。

NebulaGraph 将持续作为实时风控的底座，帮助企业在复杂关系网络中构建真正可进化的风控能力。

迎接动态风险，从拥抱实时图开始。

---
🔥推荐阅读

[《稳定币条例》强监管，图技术如何抢占风控主动权？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515838&idx=1&sn=4301cd1dce294f75f13bac03bc13e647&scene=21#wechat_redirect)

[基于知识图谱的 Web3 风控：普适智能一站式知识中台](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515978&idx=1&sn=079d22d3bf3f06b5d13e70598a081dd4&scene=21#wechat_redirect)

[NebulaGraph 在 Airwallex 跨境金融风控的应用](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515804&idx=1&sn=82973a9f946708468e9fddfd52243ebd&scene=21#wechat_redirect)

[NebulaGraph + LLM 处理风控知识图谱的探索和实践](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515771&idx=1&sn=4c8c1c729b01ddc9eca5bf0f0ad60156&scene=21#wechat_redirect)

[风控利器：BlockSec 用图+标签破解 Crypto 合规难题](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247516261&idx=1&sn=f3e91388b2a0e796801bea67bd6f9517&scene=21#wechat_redirect)



以图为底座的实时动态风控系统

快手直播事故，传统风控为何被黑产击溃？


> 图算法的小白级科普⬇️

[技术科普｜图算法是什么？何时用、怎么用？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515839&idx=1&sn=046e14a224c3f47e2a97748916d366be&scene=21#wechat_redirect)

（文章结尾有 NebulaGraph 在风控领域的用户案例合集哦～）

在电商风控战场中，黑产的手段正变得越来越隐蔽——批量注册的“垃圾账号”用不同设备登录、分散地址下单，通过“断链伪装”规避规则拦截；恶意商家联合多个账号刷单，制造虚假热销假象......传统的“单维度规则校验”（如仅判断IP是否异常、账号是否新注册）早已难以应对这种“跨主体关联作弊”。

而图算法的核心优势，正是把分散的“点”（账号、IP、设备、地址等）通过“边”（关联关系）连接成网，从“关系视角”识破黑产的集体作弊行为。

2023 年，得物风控对比了 Neo4j、Dgraph、JanusGraph、NebulaGraph，最终选择将 NebulaGraph 作为风控解决方案。

![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/dewu-risk-control/choose-graph-database.webp)

图源「得物风控」公众号

![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/dewu-risk-control/risk-control-system.webp)

图源「得物风控」公众号

今天就带大家拆解风控领域最常用的3类图算法，结合电商场景讲清算法思路和落地应用。通俗易懂无门槛～

# 一、风控里的“图”是什么？

在风控场景中，图的构成非常简单，无需复杂的数学基础就能理解：

-   节点：就是风控中的“参与主体”，比如账号、IP地址、设备ID、收货地址、手机号、银行卡号等；
    
-   边：就是主体之间的“关联关系”，比如账号A登录过IP地址B、账号C绑定了手机号D、账号E用地址F下单、账号G和H共用设备I等；
    
-   属性：节点或边的补充信息，比如账号的“注册时间”“是否实名认证”、IP的“归属地”“是否为代理IP”、关联关系的“发生时间”“频次”等。
    

举个例子：黑产用1个IP注册10个账号，这10个账号都绑定了不同的虚拟手机号，且都往同一个超市地址下单。这里的“1个IP+10个账号+10个手机号+1个地址”是节点，“注册”“绑定”“下单”是边，构成了一张典型的“黑产作弊图”。

图算法的作用，就是从这张网中找到“异常的关联模式”，比如“一个国内IP关联上百个注册账号且都是海外手机号”“多个账号共用一个设备且都有恶意下单行为”。

# 二、风控常用三大图算法及应用场景

## （一）连通分量算法：找到作弊团伙

**算法思路**

简单说就是“找圈子”——在图中找到所有相互连通的节点集合（即“连通分量”），同一个集合里的节点无论通过多少层边关联，都属于同一个“团伙”。

比如：账号A → IP → 账号B → 设备 → 账号C**，**这3个账号通过IP和设备间接连通，就会被划分为同一个连通分量，认定为“关联账号团伙”。

算法的核心价值：**把分散的作弊主体“聚合成团”，避免单个账号漏判**——黑产单个账号可能看起来“正常”（如注册时间长、有少量真实下单），但整个团伙的行为特征（如集中下单、共用资源）会暴露作弊本质。

**电商应用场景：识别“批量关联作弊”**

-   场景1：垃圾注册团伙识别

    黑产用同一IP（或代理IP池）批量注册账号，这些账号可能绑定不同手机号，但都共用某几个设备。通过连通分量算法，将“IP-账号-设备-手机号”关联的所有节点划分为一个团伙，只要团伙中部分账号被标记为“垃圾注册”，整个团伙的其他账号都会被纳入风控视野，提前拦截恶意行为（如领券、下单）。

-   场景2：刷单团伙识别
    
     恶意商家组织100个账号刷单，这些账号可能来自不同IP，但都往商家的固定商品下单，且部分账号共用支付设备。连通分量算法会将这些“账号-商品-支付设备-收货地址”关联的节点聚合成团，结合“团伙下单时间集中、收货地址相似”等特征，判定为刷单团伙，以此及时落罚恶意商家和刷单账号。
    

落地小技巧

-   对连通分量进行“大小筛选”：比如仅关注节点数≥5的团伙（避免正常用户的少量关联被误判）；
    
-   给边设置“权重”：比如“账号-设备”的关联权重高于“账号-IP”（设备唯一性更强），权重越高的边对“团伙聚合”的影响越大。
    

## （二）度中心性算法：揪出核心作弊算法思路

**算法思路**

“度”是指一个节点连接的边的数量——度中心性越高，说明这个节点和其他节点的关联越密集，越可能是“核心枢纽”。

在风控中，我们重点关注“入度”（其他节点主动关联它的次数）和“出度”（它主动关联其他节点的次数）：

-   比如一个IP的“出度”是100（关联100个账号登录），说明这个IP是批量注册/登录的核心；
    
-   一个设备的“入度”是50（50个账号共用它），说明这个设备是黑产的“共用工具”。
    

算法的核心价值：**快速定位作弊网络中的“关键节点”，精准打击黑产的“基础设施”**——查封一个核心IP/设备，可能连带阻断几十个作弊账号的操作。

**电商应用场景：打击“黑产核心资源”**

-   **场景1：识别恶意IP/设备**
    
    正常用户的IP通常只关联1-2个账号，若某IP的度中心性（关联账号数）达到50+，且关联的账号多为新注册、无实名认证，可判定为“黑产专用IP”，酌情考虑拉黑或升级管控该IP的所有后续注册/登录请求；同理，某设备关联几十个账号且都有恶意下单行为，可判定为“黑产共用设备”，酌情考虑封禁设备对应的所有账号。
    
-   **场景2：识别“养号中介”账号**
    
    部分黑产账号的核心作用是“关联其他作弊账号”（如作为“主账号”邀请新账号注册、共享优惠券），这类账号的度中心性极高（关联上百个下级账号）。通过度中心性算法识别出这类“核心中介账号”，封禁后可切断黑产的账号扩散链路。
    

**落地小技巧**

-   分维度计算度中心性：比如单独计算“IP-账号”“设备-账号”“手机号-账号”的度，避免不同维度的关联相互干扰；
    
-   结合时间窗口：比如统计“近7天”的关联度，避免长期积累的正常关联（如家庭共用IP、企业IP等）被误判。
    

##（三）密集子图挖掘算法：精准拆分隐蔽作弊小团体

**算法思路**

比连通分量算法更精细的“团伙拆分工具”——核心是在一张大范围连通的关联图中，精准定位“内部关联极密集、与外部关联极稀疏”的子图（也就是黑产实际运作的“小团体”）。

简单说：连通分量算法是“只要沾边就归为一类”（比如一个IP关联的100个账号全算一个大团伙），而密集子图挖掘是“关系够近才凑一组”——同样是100个账号关联同一个IP，其中30个账号之间还存在“互相转账、共用收货地址、交叉助力”等多重紧密关联，这30个账号就会被挖掘成一个密集子图；剩下70个账号若仅和IP有关联、彼此无交集，可能拆成多个独立的密集子图，对应不同的作弊小团体。

算法的核心价值：**打破“大团伙”的笼统判定，拆分出黑产实际运作的“作战单元”**——同一个黑产资源（如代理IP池、共用设备）可能被多个独立团伙共用，密集子图能精准区分不同团伙的作弊链路，避免对正常用户的关联误判，也为针对性打击提供依据。

**电商应用场景：精准打击“细分作弊团伙”**

-   **场景1：拆分多团伙共用资源的作弊行为**
    
    某代理IP池被3个独立黑产团伙共用，A团伙专注刷单、B团伙专注薅平台优惠券、C团伙专注恶意注册。虽然所有团伙账号都关联该IP池（属于同一个连通分量），但A团伙内部账号会频繁交叉下单、B团伙内部账号会领同一类优惠券，彼此无关联。通过密集子图挖掘，可将3个团伙拆分为3个独立的密集子图，针对A团伙封禁下单权限、B团伙限制领券、C团伙直接拦截注册，避免“一刀切”导致的误判或漏判。
    
-   **场景2：识别“跨平台协同作弊小团体”**
    
    黑产为规避单平台风控，会在电商APP、小程序、H5端分别注册账号，但这些账号会共用同一台设备、绑定同一组手机号，且存在跨平台交叉操作（如APP端领券、小程序端下单）。密集子图挖掘能跨平台聚合这些“设备-手机号-账号”关联紧密的节点，形成“跨端作弊密集子图”——即便某端账号未表现出恶意（如APP端账号仅浏览未下单），但因属于作弊密集子图，可提前限制其核心行为（如限额下单、需实名认证），阻断跨平台作弊链路。
    

**落地小技巧**

-   常用算法选择：风控场景无需复杂模型，Louvain算法（效率高、适合大规模图数据，能自动平衡子图规模）或LPA（标签传播算法，无监督、易落地、计算快）完全够用；
    
-   结合行为特征打标：挖掘出密集子图后，可根据子图内账号的核心行为（如高频下单、批量领券、恶意注册），给每个子图打上“刷单团”“薅券团”“注册机团”等标签，后续针对标签制定差异化拦截策略；
    
-   设定密度阈值：可通过“子图内实际关联数/最大可能关联数”计算密度，仅关注密度≥0.3的子图（避免正常用户的少量交叉关联被误判为作弊小团体）。
    

# 三、图算法落地关键

很多同学会问：“算法识别出团伙后，怎么落地到风控策略里？” 分享3个实战中常用的闭环逻辑：

1.分级拦截：根据连通分量大小、度中心性高低、子团伙风险概率，给节点打风险等级（高/中/低）——高风险直接封禁，中风险限制行为（如权益限制、发垃圾券等），低风险持续监控；

2.传导处罚：若一个节点被判定为恶意（如账号被封禁），其关联的节点（如登录IP、绑定设备）同步提升风险等级，实现“打一个、带一片”；

3.实时+离线结合：离线用图算法（如连通分量、密集子图发现）挖掘团伙，生成“风险团伙名单”；实时风控时，校验当前账号是否在名单中，或是否关联高风险节点，实现快速拦截。

举个落地示例：

-   离线：每天用连通分量算法聚合“账号-IP-设备-地址”强关联图，识别出节点数≥10的团伙，若团伙中恶意账号占比≥30%，标记为“高风险团伙”；
    
-   实时：用户下单时，校验该账号是否属于“高风险团伙”，或是否关联团伙中的IP/设备，若是则权益隐藏或拦截订单，提示“账号存在XX异常风险”。
    

# 四、总结经验

黑产作弊的核心本质，从来不是 “单个账号的孤立行为”，而是 “团伙化、批量化的协同操作”—— 他们通过换 IP、换设备、买号养号等手段切断单点关联，让传统规则难以追踪。而图算法的核心价值，正是**穿透这些 “断链伪装”，看透账号、IP、设备、地址背后的隐性关联**。

相较于传统规则 “头痛医头、脚痛医脚” 的单点防控，图算法实现了三大突破：

1.打破维度壁垒：不再局限于单一维度校验，而是将 “账号 - IP - 设备 - 地址 - 手机号” 等多主体联动分析，让分散的作弊行为 “串成线、聚成团”；

2.前移风控关口：即便单个账号未表现出任何恶意特征，也能通过其所属团伙的集体作弊痕迹（如共用黑产设备、关联恶意账号）提前预判风险，实现 “未发先防”；

3.直击黑产核心：精准锁定团伙的核心资源（如共用设备、批量注册 IP），避免黑产通过 “换号换 IP” 规避拦截，实现 “打一个、断一片” 的高效打击。

对风控从业者而言，图算法绝非高深莫测的数学工具，而是人人可落地的实战基操—— 只要理清 “节点（参与主体）\- 边（关联关系）” 的核心逻辑，就能快速应用于反作弊、反欺诈等核心场景，让风控从 “被动响应拦截” 升级为 “主动前置防御”。

---

NebulaGraph 风控案例

[基于知识图谱的 Web3 风控：普适智能一站式知识中台](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515978&idx=1&sn=079d22d3bf3f06b5d13e70598a081dd4&scene=21#wechat_redirect)

[风控利器：BlockSec 用图+标签破解 Crypto 合规难题](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515844&idx=1&sn=3a216c55323488cb5235f5194fa47ddd&scene=21#wechat_redirect)

[《稳定币条例》强监管，图技术如何抢占风控主动权？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515838&idx=1&sn=4301cd1dce294f75f13bac03bc13e647&scene=21#wechat_redirect)

[NebulaGraph 在 Airwallex 跨境金融风控的应用](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515804&idx=1&sn=82973a9f946708468e9fddfd52243ebd&scene=21#wechat_redirect)

[NebulaGraph + LLM 处理风控知识图谱的探索和实践](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515771&idx=1&sn=4c8c1c729b01ddc9eca5bf0f0ad60156&scene=21#wechat_redirect)

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

[中国移动：如何用 NebulaGraph 图数据库解决金融风控中的问题？](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515545&idx=1&sn=eb0187e3b42fa355e19c81bf8f0de593&scene=21#wechat_redirect)



拆解风控领域最常用的3类图算法，结合电商场景讲清算法思路和落地应用。

得物风控：风控常用图算法及应用

> 针对社区小伙伴们对 NebulaGraph 开源版与企业版的各种疑问，星云仔邀请了双方资深专家，来了一场 battle 式直播，从技术决策、企业 ROI 两大维度，对到底选 NebulaGraph 开源版还是 NebulaGraph 企业版展开辩论，并给出了专业的选型指南。如果你错过了这场精彩的直播，可以阅读本文，了解这两大版本的优势与差异～


在做图数据库选型时，我们总希望能找到一个“标准答案”，一劳永逸地选出那个“最好”的产品。

但当面对 NebulaGraph 这样的 DB-Engines 全球排名第二的开源图数据库，和基于 NebulaGraph 开发的企业级原生分布式数据库时，你会发现，这场对决更像是一场“神仙打架”，难分高下。

而真正的答案，早已藏在你的业务场景、团队能力和长期规划之中。

# NebulaGraph 开源版

## 关于 NebulaGraph 开源版

NebulaGraph 开源版是世界领先的原生分布式图数据库，擅长处理千亿节点万亿条边的超大数据集，同时保持毫秒级查询延时。

自 2019 年 5 月开源以来，被多家互联网头部企业竞相采用，广泛应用于金融风控、实时推荐、知识图谱等业务场景。早期采用者包括腾讯、美团、京东、微众银行、小红书、知乎、快手、BOSS 直聘等知名互联网企业。

随着图数据库技术的日益普及以及业务场景的不断发掘，越来越多行业加入了 NebulaGraph 开源社区，包括中国移动、众安保险、Airwallex、BlockSec 等等。

-   官网：[https://www.nebula-graph.com.cn](https://www.nebula-graph.com.cn)
    
-   论坛：[https://discuss.nebula-graph.com.cn](https://discuss.nebula-graph.com.cn)
    
-   GitHub：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula)
    
-   技术交流群：搜索微信号 NebulaGraphbot，星云仔邀请你进群
    

## 选择 NebulaGraph 开源版

选择开源版 ，就像是选择了一片充满无限可能的森林。你手握源代码这张地图，可以自由探索每一条小径，甚至开辟新路。这种深度可控带来的，是极大的灵活性和自主权。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-1.png)
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-2.png)
对于技术实力雄厚、追求极客的团队来说，开源版的魅力是无法抗拒的。零许可证费用意味着极低的启动门槛，让你的想法可以快速落地验证。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-3.png)

开放的社区让你能与全球的开发者直接交流，技术视野往往更广阔，能紧跟最前沿的技术趋势。

更重要的是，你完全避免了供应商锁定的风险，技术路线可以随着业务需求灵活调整，未来的退出成本极低。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-4.png)
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/Nebula-5.png)
正如那句名言："Talk is cheap, show me the code", 开源版的透明，构建了最坚实的信任基础。

京东、阿里、美团、网易等大型互联网公司基于开源版构建的成熟案例，也充分证明了 NebulaGraph 开源版在高并发、复杂场景下的强大实力。

# NebulaGraph 企业版

## 关于 NebulaGraph 企业版

NebulaGraph 企业版原生分布式数据库，面向企业、机构，更快更稳更易用。

企业版有丰富的企业级特性，满足多业务场景需求，全面支持信创，全项通过可信数据库产品能力测试，并提供 SLA 服务支持，专业团队提供交付实施，并支持公有/私有化的部署方式，企业用户可以按需选择，轻松享受更便捷的一站式图数据库体验。

## 选择 NebulaGraph 企业版

选择 NebulaGraph 企业版，则像是入住了一座由顶级建筑师精心打造的现代化大厦。你不必关心地基有多深、管线如何铺设，只需专注于如何在这个稳定、安全、功能齐全的空间里，高效地开展你的业务。

NebulaGraph 企业版所做的，正是将 NebulaGraph 开源版的“优质原材料”，加工成稳定、安全、可靠、易于大规模部署的“工业成品”。这对于绝大多数追求业务稳定性的企业而言，价值巨大。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/vip-1.png)
企业版提供了明确的 SLA 保障，通过了各项合规与信创认证，内置了细粒度的权限管理、审计日志和全链路加密等企业级安全特性，让你在合规道路上后顾无忧。
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/vip2.png)
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/vip-3.png)
在性能上，企业版经过了更深度的优化，在测试中实现了性能提升 3 倍以上，内存开销降低近 90% 的惊人表现，这意味着更低的硬件成本和更强的业务支撑能力。

此外，官方提供的专业交付、培训和技术支持，能将你的团队从复杂的基础设施运维中解放出来，真正聚焦于业务创新，从而在长期范围内实现更可控、更优的总体投资回报。

# 选型指南
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/Nebula-comparison/how-to-choose.drawio-2.png)

那么，究竟该如何抉择？与其纠结于哪个更好，不如回归本质，审视自身：

**1\. 你的业务需求是什么？**

如果你的业务场景对图数据库的功能需求较为标准，并发和数据量在可预估的范围内，且不要求企业级的监控、审计等高阶功能，NebulaGraph 开源版就足以支撑。反之，如果你的业务是像实时风控、供应链关系追溯等需要处理极端并发、复杂深度查询、并具备全面可观测性的核心场景，NebulaGraph 企业版所提供的完整功能栈和性能保障则至关重要。

**2\. 你的团队技术能力如何？**

如果你的团队有强大的运维和源码级定制能力，享受从零到一的构建过程，NebulaGraph 开源版是你的绝佳舞台。反之，如果你的团队希望更专注于业务逻辑，不愿在底层基础设施上投入过多精力，NebulaGraph 企业版能让你事半功倍。

**3\. 你的业务对稳定性和安全性的要求有多高？**

如果你的业务处于金融、政务等对稳定、安全、合规有严苛要求的领域，NebulaGraph 企业版提供的 SLA 保障和全面信创支持即是刚需。而对于尝试性项目或内部工具，开源版的灵活性和低成本则更具吸引力。

**4\. 你的长期规划是什么？**

是希望快速试错、小步快跑，还是计划打造一个需要长期服役、持续扩展的核心系统？前者或许更适合轻量级的开源起步，后者则更需要长期、稳定、专业的企业级支持。

归根结底，NebulaGraph 开源版与 NebulaGraph 企业版并非站在对立面，而是服务于不同阶段、不同需求用户的最佳实践方案。


# 合适的，才是最好的

读到这里，聪明的你一定 get 了重点：选 NebulaGraph 开源版 还是NebulaGraph 企业版，没有标准答案，所谓的 battle 也只是在还原大家在选型时的心路历程。

到底怎么选，取决于哪一个版本最适合你的业务场景，同时团队的定制开发能力，也会影响选型结果。

如果你参照了上述选型指南还是拿不定主意，可以先参照详细的文档，部署上手 NebulaGraph 开源版，尝试把它落地生产，在实践中再结合业务需要考虑是否升级为企业版

文档：[https://docs.nebula-graph.com.cn/3.8.0/](https://docs.nebula-graph.com.cn/3.8.0/)

**无论怎么选，都祝大家在图的世界里玩得开心～**

 NebulaGraph 开源版与企业版产品对比、选型参考

NebulaGraph 开源版与企业版选型指南

> 导读：图数据库的核心价值在于揭示数据之间隐藏的复杂关系。NebulaGraph 支持丰富的图算法，将隐秘关系高效转化为 actionable 的洞见。
> 本期技术科普将带你了解图算法与 NebulaGraph Algorithm，看看 NebulaGraph 社区用户如何将这些图算法用于生产环境以及如何上手。



# **一、** 图数据库与图算法

## （一）什么是“图”？

想象一下你有一张**关系网**：

**1\. 点**：代表独立的实体。比如：

-   你微信里的所有好友。
    
-   城市地图上的所有十字路口。
    
-   一个项目里的所有任务。
    

2.**线**：代表这些实体之间的关系。比如：

-   微信里，你和某个好友是“好友关系”（一条线连着你俩）。
    
-   城市地图上，两个十字路口之间有一条“道路”（一条线连着两个路口）。
    
-   项目里，任务 A 必须在任务 B 开始之前完成（一条线从 A 指向 B，表示依赖）。
    

这种由“点”（图数据库中的顶点或节点）和连接它们的“线”（图数据库中的边）组成的结构，就叫做“图”。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/nebula-graph-studio-case.webp)

（用 NebulaGraph Studio 进行某公司股权穿透）

## （二）什么是图算法？

图算法就是一套聪明的“解题思路”或“工具包”，专门用来分析这种“点”和“线”组成的关系网，计算关于这个网络的问题。

**为什么需要专门的“图算法”？**

-   **超越简单查询**：传统查询能找到直接邻居，但图算法能分析整个网络的结构和动态。
    
-   **量化关系价值**：把模糊的“关联”变成可计算的指标（如重要性、紧密度、相似度）。
    
-   **发现隐藏模式**：自动识别传统关系数据库难以查询的社群、关键枢纽、传播路径。
    

**图算法的应用**

**找最短路径：**

-   **问题**：从家（点A）导航到公司（点B），导航如何规划最快/综合成本最低的路线？
    
-   **图算法**：经典的最短路径算法（如 Dijkstra 算法），能快速计算出从 A 到 B 的所有可能路线中，总权重（通常代表路程长度、通行时间或综合成本）最小的那条路径。
    

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/dijkstra.webp)

**好友推荐：**

-   **问题**：微信/微博/Facebook 怎么知道你可能认识谁，从而给你推荐好友？
    
-   **图算法**：基于共同邻居的链路预测算法（如 Jaccard 算法）会分析你的社交网络图：关注你的直接好友（一度邻居），然后考察他们的好友（你的二度邻居）。那些与你拥有大量共同好友（即共同的一度邻居） 但尚未与你建立连接的人，就很可能被推荐给你。
    
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/jaccard.webp)

**网页排名：**

-   **问题**：搜索引擎怎么决定当你搜索“图算法”时，哪个网页应该排在前面？
    
-   **图算法**：PageRank 算法。它的核心思想是：
    
-   被很多其他网页链接指向的网页（点），通常比较重要（票数多）。
    
-   被一个重要网页链接指向的网页，也会获得更高的重要性（重要的一票更有分量）。
    
-   算法会不断计算每个网页的“重要性得分”，得分高的排名就靠前。
    
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/page-rank.webp)

# **二、图算法类型及应用场景**

图算法大致可分为以下几种类型：

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/%20algorithm-over-view.webp)

# **三、NebulaGraph Algorithm**

NebulaGraph Algorithm 是一款基于 GraphX 的 Spark 应用程序，通过提交 Spark 任务的形式使用完整的算法工具对 NebulaGraph 数据库中的数据执行图计算，也可以通过编程形式调用 lib 库下的算法针对 DataFrame 执行图计算。

## （一）NebulaGraph 支持的图算法

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/nebula-graph-algorithm-overview.webp)

> 上图为社区版支持的基础图算法，企业版支持更多高性能算法（如 InfoMap、APSP、DegreeWithTime、HyperANF 等）及基于 ISO-GQL 的自定义图算法。

## （二）NebulaGraph 用户这么用

**NebulaGraph 用户们如何用图算法解锁业务价值？**


### **1、中心性分析-PageRank**

-   **何时用**：当你需要找出整个网络中“影响力大”或“被广泛引用/连接”的节点时。
    
-   **场景举例**：识别社交媒体上的关键意见领袖；在金融交易网络中定位核心中转账户。
    
-   **社区用户**：[Boss 直聘](https://www.nebula-graph.com.cn/posts/NebulaGraph-use-case-BOSS-zhipin)整合链路追踪（Trace）、系统指标（Metrics）、日志（Logs）三大数据源，构建统一的全链路异常拓扑图，发现多个真子图分散出现在图结构中，每个子图都有“风暴中心”，故采用 PageRank 算法动态计算节点故障权重（Rank 值由节点出入度、链路错误数、事件进行加权计算），得出 Rank 值最高的 TopN 故障节点（即 “风景眼”），从而快速实现根因定位，平均收敛时间仅 20s.
    

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/boss-use-nebula.webp)

### **2、 社区发现-Louvain、Hanp**

-   **何时用**？需要在大规模网络中发现层次化的社区结构时。
    
-   **场景举例**：社交网络中的兴趣社群划分；电商用户群体细分（购买模式相似）；城市交通流量分区。
    
-   **社区用户**：[中国移动](https://www.nebula-graph.com.cn/posts/cmcc-financial-riskcontrol-practice)首先基于所有移动用户构建一个关系网络，采用 Louvain、Hanp 算法进行社区发现与挖掘，如个人的信用评分以及个人之间的关系，然后对这个社区进行打分，识别出这个社区是否为一个欺诈社区或者是一个低信用的社区，从而进行风险管理。
    
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/zhongguoyidong-use-nebula.webp)

### **3、社区发现-LabelPropagation**

-   **何时用**？需要快速发现社区，或者网络结构清晰、社区边界明显时。
    
-   **场景举例**：实时推荐系统中的用户兴趣圈识别；新闻/信息传播路径上的群体划分。
    
-   **社区用户**：在[众安保险](https://www.nebula-graph.com.cn/posts/zhongan-insurance-knowledge-graph-practice)，LabelPropagation 应用于贷中环节。LabelPropagation 主要是通过一个确定的点 Y 去传播、衍生出它相关点。比如，贷中用户名单中某个用户是严重逾期人员，这个人员便是打上逾期标签的确定点 Y，结合既定的风控规则查看点 Y 关联延伸的点中哪些点出现相似逾期行为，从而判断这些点是否属于严重逾期的社群。
    

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/zhonganbaoxian-use-nebula.webp)

### **4、ConnectedComponent/StronglyConnectedComponent**

-   **何时用？** **CC** (弱连通分量)关心是否可以通过路径（忽略边方向）连通。用于发现孤岛。SCC (强连通分量)：关心是否可以通过有向路径互相到达。用于分析紧密循环依赖。
    
-   **场景举例**：分析社交网络中的孤立用户群体 (`CC`)；研究论文引用网络中的研究学派 (`SCC`)；分析系统模块间的循环依赖 (`SCC`)。
    
-   **社区用户**：[众安保险](https://www.nebula-graph.com.cn/posts/zhongan-insurance-knowledge-graph-practice)使用 ConnectedComponent 计算出用户关系图谱。当发现一个手机号被异常数量（如五六十人）标记为“家庭联系人”时，该手机号及其关联用户即构成一个潜在风险社群。处于此类异常社群是用户风险的强信号（充分不必要条件），用户也可能是因亲属涉黑产而被牵连。众安据此对社群内用户进行初步风控标记和深入核查。
    

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/zhonganbaoxian-use-nebula.webp)

# 四、NebulaGraph AI Suite

除了 NebulaGraph Algorithm, @wey 在 2023 年为社区提供了一个名为 NebulaGraph AI Suite 的项目，它是在 NebulaGraph 之上跑算法的 Python 套件，能给用户一个自然、简洁的高级 API。简单来说，用很少的代码量就可以执行图上的算法相关的任务。

在[《手把手教你用 NebulaGraph AI 全家桶跑图算法》](https://www.nebula-graph.com.cn/posts/nebulagraph-ai)中，@wey 给出了详细的上手教程。该项目完全开源，如果你有新的 idea, 欢迎共建～

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/what-is-graph-algorithm/nebula-ai-suite.png)


# 五、行动起来～

NebulaGraph Algorithm，提供了一套强大的“关系显微镜”。那些困扰你的问题（谁最重要？哪些人是一伙的？最优路径怎么走？）是否能用图算法来解决？访问 NebulaGraph 官方文档，深入了解 NebulaGraph Algorithm 的配置细节，开始你的图算法探索之旅吧！

文档🔍⬇️

[https://docs.nebula-graph.com.cn/3.8.0/graph-computing/nebula-algorithm](https://docs.nebula-graph.com.cn/3.8.0/graph-computing/nebula-algorithm)

---

[香港 nMeetUp](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247517169&idx=1&sn=ab591d3a4bb66d9e5cd65caaf59b7100&scene=21#wechat_redirect) 报名中🔥

进一步探索 NebulaGraph 在#知识图谱、#Web3、#金融风控 的最新应用

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




带你了解图算法与 NebulaGraph Algorithm，看看 NebulaGraph 社区用户如何将这些图算法用于生产环境以及如何上手。


技术科普｜图算法是什么？何时用、怎么用？


> 导读：本文整理自 NebulaGraph 解决方案架构师@鲍翰林的分享，文末附分享回放与 PPT 下载。


8 月 1 日，香港《稳定币条例》正式生效，这是全球首个针对法币稳定币的全面监管框架，标志着稳定币行业迈入强监管时代。条例核心要求清晰而严格：锚定法定货币、需持牌经营、100%资产储备、充分披露、定期审计、遵守 KYC/AML.

新规之下，行业如何构建满足监管要求、抵御复杂风险的风控体系？图技术正凭借其深度关系挖掘、实时风险洞察的独特能力，成为 Web3 合规风控的新基石。


# 一、强监管时代，传统风控力不从心

传统数据库无法构建稳定币的关系网络

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-risk-control.png)

* **脱锚隐患**：链上风险叠加传统金融风险外溢，易引发价格脱钩。
* **黑产猖獗**：黑客盗币、洗钱、批量注册套利等行为利用链上匿名性隐蔽操作。

* **数据孤岛**：传统风控依赖“表单式”数据分析，难以穿透多跳地址、识别跨平台关联团伙。

**稳定币风控的核心痛点在于全是“关系”**，本质是关系密集型、路径驱动型的：黑客的一次盗币往往涉及“异地登录→异常设备→快速创建 API→卖币→提币至陌生地址”的完整行为链，并通过多跳地址转移资金。

**关系型数据库在建模复杂实体关系（如“IP-设备-地址-交易”的多维关联）、执行深度链路查询（如追踪 5 层转账路径）时存在天然瓶颈**，导致风险漏判与响应滞后，面对加密世界复杂、动态的“关系网”？显然力不从心。

[复杂关系场景，图数据库为何是首选？](https://discuss.nebula-graph.com.cn/t/topic/16889)


# 二、图数据库天然适配 Web3 风控

图数据库以“点”（即实体，如人、地址、设备）和“边”（即关系，如 A 给哪些账户转账、B 用了哪些不同设备登录）建模现实世界，天然契合 Web3 多源异构、强关联的数据特征。

基于 NebulaGraph 的风控解决方案架构分为三层：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-solution.png)

## 数据层：融合链上链下全域数据
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-web3-data.png)

整合链上地址（Crypto Address）、交易记录（Blockchain TX）、用户 KYC 信息（ID/Phone/Email）、支付渠道（Card/Fiat）、设备指纹（IP/FVIDEO）等，构建千亿点万亿边的统一图模型，为关系网络分析奠定基础。


## 图引擎层：分布式计算与实时分析


### 1. 社区发现算法（WCC/Louvain）：

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-web3-algorithm.png)

自动聚类高风险团伙。例如，通过关联共用IP、设备或资金汇入同一“黑洞地址”的账户群，揪出背后操控的“羊毛党军团”。


### 2. 实时图规则引擎：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-real-time.png)

毫秒级识别风险模式。如“5 分钟内同一 IP 登录 10+地址”触发盗号预警；“多地址向未关联 KYC 的新地址大额转账”触发洗钱拦截。


### 3. 多跳穿透查询：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-control/nebula-web3-query.png)

秒级追踪 N 层资金链路。结合区块高度与时序过滤，精准还原黑客的混币路径。


### 4. 应用层：驱动风控全流程升级

* 事前预警：基于图特征（出入度、中心性、社区紧密度）动态生成策略。
* 事中决策：实时扫描 N 度关联实体，风险扩散拦截（如标记一个涉诈钱包，自动冻结其紧密关联账户）。
* 事后分析：可视化还原攻击路径，辅助审计举证。


> 算法突破：相比 GraphX ，NebulaGraph 企业版在算法性能上实现 10-100 倍提升，内存开销降低 5 倍，并支持 ISO-GQL ，降低开发门槛。



# 三、NebulaGraph x Web3 风控案例


## 百亿级 CSI 风控平台

**挑战**：交易所日交易量超百亿美元，需在海量数据中识别洗钱、市场操控等可疑活动，满足严格 AML/KYC 要求。

**方案**：基于 NebulaGraph 构建 40 亿点、400 亿边的风控图谱，融合链上/链下数据。

**价值**：
* 秒级穿透交易链路：追踪资金多层流转路径。
* 精准识别跨平台风险：发现隐匿的关联账户网络。
* 自动化合规报告：提升审计可解释性与监管透明度。


## 交易所实时营销反作弊

**挑战**：某交易所空投活动中，80% 的高额奖励被 5% 的地址盗走，羊毛党利用“设备农场”控制数百地址套利。

**方案**：构建 3000 万点、20 亿边的用户-设备-活动图谱，实时分析关联。

**价值**：

* 误报率降至 5% 以下：精准识别“单点正常、群体异常”的作弊集群。
* 50 毫秒完成 3 跳查询：实时拦截批量注册与套利行为。
* 存储减 40%，算力省 60%：大幅优化资源成本。


## 链上资金追踪

**挑战**：黑客利用多跳地址和混币器隐藏路径，传统分析难以追踪。

**方案**：整合 30亿+ 标签地址，构建 3 亿节点、10 亿边资金流图。

价值：

* 深度交易图谱分析：还原跨链洗钱与攻击路径。
* “地址健康度”画像：动态评估风险等级。
* API 响应<1.5 秒：支撑实时合规审查。


# 四、Ending

当链上风险日益复杂化、隐蔽化，传统风控手段已显疲态。NebulaGraph 凭借深度关系挖掘、实时多跳穿透、动态风险扩散的能力，为监管机构与 Web3 企业提供了关键基础设施：

* **对稳定币发行方**：确保 100% 储备透明可追溯，满足定期审计要求。
* **对交易所/钱包**：实现毫秒级反欺诈、反洗钱拦截，降低合规成本。
* **对监管机构**：获得可解释、可验证的全链资金视图，提升监管效率。



**🎯联系我们**

填写 NebulaGraph 企业版咨询问卷，根据你的业务场景与需求，我们将安排相关人员为您提供专业解决方案。

*🫱https://www.nebula-graph.com.cn/contact*

**⏬直播回放及 PPT 下载**

访问 NebulaGraph 论坛下载 PPT.


**[🔥香港 nMeetUp 报名中](https://mp.weixin.qq.com/s/wxMFmd3Ny45M8yv6wuOtAw)**

进一步探索 NebulaGraph 在知识图谱、Web3、金融风控的最新应用



《稳定币条例》颁布，进入稳定币强监管时代，传统风控力不从心，如何利用 NebulaGraph 抢占风控主动权？

《稳定币条例》强监管，图技术如何抢占风控主动权？

**2025 年 8 月 1 日，中国香港《稳定币条例》即将正式生效，这是全球首个针对法定稳定币的全面监管框架**。新规要求发行机构实施与传统金融同等级的 KYC/AML 流程，对单笔超 10万港元交易执行强化尽调，并确保储备资产 100% 隔离存放。

国际清算银行（BIS）近期报告则警示：稳定币的跨境伪匿名特性正加剧洗钱风险，传统风控体系面临失效危机。

**在这场政策收紧风暴中，发行机构面临的核心矛盾已浮出水面：**

政策要求发行机构必须实现资产挂钩透明化 、跨境交易可追溯 、用户身份穿透式管理 ，但传统风控体系对复杂关系网络的识别能力已接近极限。




# 一、传统风控失效
## 身份关联的复杂性成为首要难题

香港条例强制要求用户身份与链上地址绑定，但某跨境洗钱案中，单个犯罪者操控超过 200 个钱包地址分散资金。传统系统依赖静态规则和简单关联分析，无法动态识别此类集群化行为。


## 跨境资金追踪的滞后性进一步放大风险

稳定币通过跨链桥实现多链资产转移，资金路径被切割成碎片化轨迹。BIS 数据显示，43% 的洗钱交易因风控响应延迟得逞，而美国法案要求的 10 分钟冻结时限，对传统小时级扫描的系统构成严峻挑战。


## 系统性风险的传导失控更值得警惕

中国香港的条例赋予用户对发行方储备资产的优先索赔权，一旦某稳定币出现挤兑，其托管银行可能因连带责任陷入流动性危机。当前风控系统缺乏对“发行方-银行-债权人”网状关系的动态模拟能力，无法预判风险传染路径。

# 二、NebulaGraph 的风控解决方案

面对上述挑战，NebulaGraph 正成为头部发行机构的核心选择。其技术价值已在生产环境中得到验证：

## 动态图谱：实时更新全景数据，应对跨境监管压力

稳定币的跨链特性导致资金路径碎片化，传统风控系统因数据割裂无法快速串联完整轨迹。

NebulaGraph 通过多链交易关联图谱技术 ，将不同公链（如比特币、以太坊、Solana）上的地址、时间戳和金额统一建模，形成全景资金流向视图。可毫秒级更新地址关联网络，捕捉犯罪者频繁切换钱包的动态行为。

> 某跨境支付平台通过最短路径分析，秒级串联一笔稳定币从 TRON 链到 ETH 链的完整转移路径，并实时评估风险等级。这种动态图谱能力还支持一键生成符合多国监管要求的证据链，大幅缩短合规响应时间。

## 图计算：穿透复杂关系网络，精准识别隐藏风险

稳定币发行机构面临的核心挑战之一是用户身份与链上地址的深度关联 。传统风控依赖静态规则（如黑名单匹配）或简单关联分析，难以应对犯罪者操控数百个地址分散资金的“集群化”攻击。

NebulaGraph 通过图计算，将用户身份、链上地址、设备指纹、交易时间戳等多维度数据构建成动态演进的关系网络 ，利用社区发现算法自动识别隐藏的资金池。

> 在某跨境洗钱案中，系统通过分析 200+ 地址的交易模式，发现其资金流转路径与正常用户显著偏离，毫秒级锁定幕后控制者。此外，图计算还可模拟“发行方-银行-债权人”的网状依赖关系，预测稳定币挤兑引发的流动性危机传导路径，为机构提供风险传染的预警模型。

## 实时图特征：高并发下的毫秒级响应，守护系统性安全

在高负载场景下，稳定币发行机构需应对突发流量洪峰，如市场剧烈波动时的交易激增，同时满足监管对实时风险拦截的要求。传统数据库在每秒数千次的复杂关联查询时便可能出现延迟，而 NebulaGraph 已在实战中验证其万亿级实时关联分析能力。

NebulaGraph 基于分布式架构，支持每秒数万次高并发查询，即使面对极端场景仍能稳定输出毫秒级响应。这种实时能力不仅满足监管时效要求，更可主动拦截洗钱、挤兑等系统性风险，守护机构稳健运营。


# 三、结语

中国香港《稳定币条例》生效仅剩15天——合规能力正从成本项转化为生存资格证。稳定币监管收紧只是开始，未来政策将进一步向 DeFi 协议 、NFT 金融化等领域延伸。

当传统金融机构仍在链上数据整合中挣扎时，先行者已借 NebulaGraph 建立起风控护城河。

**越早构建“关系认知”，越能在政策变局中掌握主动权！**


# NebulaGraph 直播

**扫码预约 NebulaGraph 直播：图技术如何抢占稳定币风控主动权？**
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/stablecoin-risk-control.jpg)

技术科普｜稳定币监管全面升级，发行机构如何应对风控新挑战？


> 关于作者：张潇老师，10 年全职 DBA，3 年数据库产品经理，目前担任证券行业数据治理与数据技术。墨天轮ID“多明戈教你玩狼人杀”。本文源自张潇老师在[北京 nMeetUp](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516965&idx=1&sn=7e7030ee6d437721e5b50f82009defa4&scene=21#wechat_redirect) 上的分享。

《[从关系视图炼狱到关系图谱自由：手把手教业务部门用图数据库逆袭](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515568&idx=1&sn=f119cbc49fbd480e9f4c9db4ff1d767c&scene=21#wechat_redirect)》一文曾经提到，关系型数据库与现实中的关系往往存在一个鸿沟，那么我们今天再次展开，从理论出发，来聊聊关系型数据库无法直观显示“关系”的悖论。


# ▌一、为何“关系”成为数据库的阿喀琉斯之踵？

> 阿喀琉斯之踵（Achilles' Heel），原指阿喀琉斯的脚后跟，因是其身体唯一一处没有浸泡到冥河水的地方，成为他唯一的弱点。阿喀琉斯后来在特洛伊战争中被毒箭射中脚踝而丧命。现引申为致命的弱点、要害。

如果大家做过面向对象编程，那么对于关系型数据库的表以及类之间的异曲同工会有心得。本质上，这两者都是对于现实世界各种属性的抽象和建模。它们在软件开发中常常被一起使用，也能够印证其中的关联。

然而，如果我想要表达两个实体之间的“关系”又该怎么办？比如客户经理 A 服务于客户 A，客户经理助理 A 又服务于客户经理 A？那么我们往往会创建三张表，分别代表三个不同的角色，再使用外键或者维护一张关系表来做关系的对应。

![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/7-8/relational-database-table1.webp)


![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/7-8/relational-database-table2.webp)

![图片](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/7-8/relational-database-table3.webp)
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/7-8/relational-database-table4.webp)

那么，我想要获取某个客户是哪个客户经理服务，这个客户经理又有哪些客户经理助理，就需要一个多表 JOIN：

```
SELECT 
    c.customer_name AS 客户名称,
    m.manager_name AS 客户经理姓名,
    ma.assistant_name AS 助理姓名,
    m.manager_email AS 客户经理邮箱,
    ma.assistant_email AS 助理邮箱
FROM 
    customers c
JOIN 
    customer_manager_relationship cmr ON c.customer_id = cmr.customer_id
JOIN 
    managers m ON cmr.manager_id = m.manager_id
JOIN 
    manager_assistants ma ON m.manager_id = ma.associated_manager_id
WHERE 
    c.customer_name = '客户 A'; 
```

三张表的 JOIN，就意味着随着数据量的提升，有可能出现查询性能的断崖式下滑。过往很多互联网公司，往往会有不允许超过几张表的 JOIN 的“军规”就是来自于此。

这背后的本质在于，**外键无语义描述能力，无法表达关系的强度、类型等属性，难以满足复杂关系的存储需求。即便是如今关系型数据库已经如此强大，仍然有着它们无法有效覆盖到的场景。**

然而，人际关系的复杂之处就在于此，我们现实中的人际关系是动态的网状结构，非静态层级，随时可能发生变化，难以用传统的表结构来准确表述——我遇见谁会有怎样的对白，我等的人她在多远的未来。

就比如 Jack Ma 背后有哪些企业和关联人，这些关联的任何企业具体和他又是什么关系，**用关系型数据库可以表述，但是在查询时带来的复杂度以及性能开销，都是远超我们想象的。其中任何一环有了变化，都会引起滚雪球一样的修改。**

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/7-8/jack-ma-graph.webp)
（用图来表示 Jack Ma 和其企业的关系）

# ▌二、图数据库：存储逻辑的重构哲学

我们仍然从理论出发，图数据库表达“关系”时，有哪些先天优势。

## （一）图数据库三要素天然适配关系

**顶点**：人/物（携带属性），如姓名、年龄等，是关系的主体。一个顶点有时候更像关系型数据库中的一条记录，包含了属性，同时代表一个确定的实体。

**边**：关系（可携带权重、类型），如亲密度、时间等，是关系的连接。边在关系型数据库里怎么直接描述？外键或者其他方式的引用，但是图数据库中，一条记录足以，甚至表达更加简练精确。

**属性**：为顶点和边提供详细信息，丰富关系的语义。顶点和边都可以带属性，比如顶点里人有年龄有身高，边的属性里有关系的走向以及关系的具体定义等等。

那么与关系型数据库相比，图数据库的差异就很明显：

**1. 关系表达**：关系型数据库采用隐式表达（外键约束），图数据库采用显式（一等公民）直接存储关系。

**2. 查询模式**：关系型数据库集合操作，图数据库图遍历。

## （二）图数据库查询语言深度挖掘隐藏信息

既然关系表达和查询模式存在差异，那么必然就会带来查询语言的不同，SQL 查询作为结构化查询，有着自己先天的优势，但是在面对复杂关系时，就会有自己的局限性。

比如，查询黄晓明和李晨的关系，以及他们有没有共同的朋友或者间接合作的企业，SQL 语言就存在局限：需要显式指定 Join 路径，并且路径固化，难以应对动态关系查询。

那么如果用图数据库语言来查询，不但代码简洁，还可以通过查询关系深度挖掘到更多不同的信息。

此外，在黄晓明和李晨的关系中，深度一度，可以获取他们直接的商业关联，二度还可以发现共同的朋友以及互相的商业关系——这是 SQL 语言不擅长的。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/7-8/nebulagraph-Studio.webp)
（用 NebulaGraph 进行某公司股权穿透）

# ▌三、NebulaGraph 如何重构关系存储

首先我们还是拿开篇提到的：客户、客户经理、客户经理助理三者关系，来规划一下图数据库的模型：顶点（tag）代表实体，边（edge）代表关系，而两者有各自属性（Property）。

那么我想查询某个客户关联的关系，该怎么查？

```
-- 查询客户A的客户经理及其助理信息
MATCH (c:Customer {customer_name: '客户A'})-[:Managed_By]->(m:Manager)-[:Assisted_By]->(a:Assistant)
RETURN c.customer_name AS 客户名称, m.manager_name AS 客户经理姓名, a.assistant_name AS 助理姓名, m.manager_email AS 客户经理邮箱, a.assistant_email AS 助理邮箱;
```

不需要考虑多表 Join 的逻辑，只需要找到客户姓名是客户 A 的客户，对应关系是 Managed_By 的客户经理以及关系是 Assisted_By 的客户经理助理即可，而因为是遍历，性能方面比起多表 join 也有了很强的性能提升。用 NebulaGraph ，上万条信息记录，可实现毫秒级查询。

为实现在处理千亿节点万亿条边的超大数据集时，也能提供毫秒级查询的解决方案，NebulaGraph 在核心设计上做出了多项关键努力：
![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/7-8/nebulagraph-architecture.webp)

**架构层面**：采用**存算分离架构**，支持计算层与存储层的独立、灵活扩缩容，有效应对负载变化与数据增长。

**数据模型层面**：提供强 Schema 的灵活属性图模型，支持对点、边、及其属性进行便捷的定义、添加与修改，满足复杂业务建模需求。

**查询模式层面**：基于原生图存储引擎与免索引邻接的核心优势，通过高效的图遍历模式查询，使得在深度关联查询（尤其是多跳查询）场景下，随着数据规模的增长，其性能优势相比传统关系型数据库愈发显著。

# ▌四、NebulaGraph 的应用

在过去的一段时间里，我做了如下探索和测试：

**社交网络分析**
1. 合规检测：识别洗钱或黑产团伙，通过关联的设备或者账号，在反洗钱方面的应用。
2. 人际关系分析：关键节点挖掘，例如高净值客户识别，通过股权穿透、周围强人际关系等等。

**金融风控**
1. 实时反欺诈：闭环交易检测，在关系型数据库中不能直观反映的A→B→C→A路径分析。
2. 知识图谱构建：比如企业股权穿透，让多层持股关系可视化。

**Graph+AI（规划中）**
1. GraphRAG：知识图谱增强大模型推理，这部分具体怎么做还想看看其他同行的探索。
2. Text2 GQL：自然语言转查询语句，目的是让业务部门自助完成各类数据查询工作。

# ▌五、结语

**总之，当你需要处理大规模复杂关系数据并追求高效查询时，NebulaGraph 作为一款开源分布式图数据库，能够有效解决这一核心挑战**。

最后依旧要强调，每一种数据库有着自己的擅长的领域与场景，我们去研究关系型数据库、文档数据库、图数据库，最终目的不是为了谁替代谁，而是在不同场景里综合选择当下最合适的方案。



**✨更多关系型数据库与图数据库的对比，可[查看这里](https://www.nebula-graph.com.cn/posts/graph-database-vs-relational-database)～**


‍

​

图数据库与关系型数据库的对比

复杂关系场景，图数据库为何是首选？


> 导读：「分布式锁」技术科普系列，由 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 真的安全吗？

> 导读：「分布式锁」技术科普系列，由 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)



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