Neo4j 3.1支持因果集群并改进了安全_安全_Srini Penchikala

2天时间，聊今年最热的 Agent、上下文工程、AI 产品创新等话题。2025 年最后一场~ 了解详情 



 写点什么

Neo4j 团队最近发布了Neo4j 图数据库3.1 版，该最新版的NoSQL 图数据库 Neo4j 提供了因果集群（Causal Clustering）技术和新的安全架构。

因果集群技术基于 Raft 协议开发，可使 Neo4j 支持数据中心和云所用的大规模集群和多种集群拓扑。该技术中内置了由 Neo4j Bolt 驱动处理的负载均衡。Neo4j 数据库还支持新的集群可感知会话，该会话同样是由 Bolt 驱动管理，有助于为开发人员解决架构上的问题。

安全性改进包括了如下的特性：多用户、基于角色的访问控制（提供四种预定义的全局图数据访问角色：读取者、发布者、架构者和管理者）、查询及安全事件日志、列出并终止运行中的查询，以及细粒度的访问控制等。

其它最新版本的特性还包括具有更有效空间管理的数据库内核改进，以及显示即刻图模型的模式查看器（Schema Viewer）。

针对该新版本，InfoQ 访谈了Neo4j 团队的Michael Hunger。

InfoQ：您能为我们介绍一下 Neo4j 3.1 版新提供的因果集群技术吗？与传统的集群技术相比，该技术有哪些不同？

Michael Hunger：新提供的因果集群是一种用于交易数据库集群的全新架构和方法。该方法的实现独立于以前版本中的 Neo4j 高可用（HA）技术，解决了 HA 方法中存在的一些问题。

因果集群主要着眼于提供全面的数据安全，即事务安全操作和可用性。该技术的构建一方面基于 Neo4j 一贯具备的强事务支持，这是通过 Raft 协议实现的；另一方面基于异步复制协议，它扩展了“读自写”（read-your-own-writes）一致性保证，可用于非常大规模的集群。

最终一致性是大多数 NoSQL 数据库的默认选项，但它并不支持该模型。尽管“读自写”的工作方式类似于标准的冯·诺依曼计算架构，因而是一种为人所熟知的模型，但是大多数 NoSQL 数据库还是要强制开发人员在应用中三番五次地处理一致性问题。

“读自写”问题对于任何数据库集群都是难以解决的问题，尤其是具有最终一致性的数据库集群。通常该问题由粘性会话（Sticky Session）处理。粘性会话将后续的读操作重定向到被写入的服务器，这种做法限制了可扩展性。

因果集群提供了远超最终一致性的、最为简单但最充分的一致性保证，即无论集群的规模如何，你都可随后读取你所写的。

对于因果一致性（即由因果集群所提供的一致性保证），这里额外给出两个资源：一篇外部的论文，以及关于因果一致性的背景信息。

新的因果集群在架构上具有两个主要组成部分：

一个服务器核心（Core），它接受写操作，并对数据安全做断言。核心组成了实际的（活跃的）集群。它使用 Raft 协议，为仲裁（Quorum）写操作、集群成员信息和领导者（Leader）信息等一系列集群操作提供一致性。
任意数量的读副本服务器，使得图查询可以横向扩展。

在“ Neo4j 操作手册”中有专门的章节介绍集群设置和操作，内容中还包括循序渐进教程和设置的细节。

高可用和数据安全：

数据安全确保了高可用（也就是故障转移）。数据安全由集群核心内的仲裁写操作提供。任何对核心的写操作必须被绝大多数的服务器认可，并且要先于提交向客户返回成功。Raft 协议表明，这样的操作是安全的。

这就是为什么依照 CAP 定理 Neo4j 集群是一致的和分区容忍的（CP）。在网络发生拆分时，大多数成员将会继续接受写入。如果使用了具有标签的因果一致性，不会对少数成员的读操作给出过期的数据，而是对孤儿实例上的操作做超时处理。如果没有使用标签，那么少数成员将会提供其所具有的数据。这意味着 Neo4j 永不会返回过期的或不正确的数据。在产生病理性失败的场景下，集群将最终成为只读的。

Neo4j 因果集群的实现是通过一种基于事务的标签机制，该机制使得你可从自身的写操作中获取标签记号，该标签表示了写操作（严格单调）的事务标识。在随后的操作中，你就可以使用该标签确保仅是在事务状态读取的，或仅是超越事务状态读取的。

Neo4j 官方驱动也是集群可感知的，并支持内建的智能路由协议（bolt+routing://any-server:port）。该协议负责指明当前的操作将导向何处（写、读、标签）。

扩展：

Neo4j 集群核心的部署也可跨越数据中心，提供全球规模服务。为允许面向终端用户的应用，可以用任意数量的读取副本扩展你的集群。这些副本并非集群成员，不参与写操作，并且是最终一致的。

前面所提到的标签特性依然允许“读自写”。读副本也可用于配置图计算操作所用的专用报告实例或服务器。

为实现地理范围上的可用性，可以将核心机器扩散到不同的数据中心中。虽然这样做意味着提交路径将跨越 WAN，但是由于 Raft 的特性，提交的执行将依照大多数成员所具有的最快速度。因此如果你在纽约、波士顿和伦敦有数据中心，那么事务提交的下限很有可能是纽约和波士顿间的最短网络路径，而非跨越大西洋到伦敦的较长路径。

InfoQ：Neo4j 的新安全基础是什么？它们与 Neo4j 已支持的安全特性相比有哪些差异？

Michael Hunger： Neo4j 曾具有单一的内建用户，由该用户提供对恶意攻击的防护，这是因为数据库被认为是运行于受保护的网络中。

在听取了客户的意见后，尤其是来自金融和国营部门的客户，我们决定自 3.1 版开始为 Neo4j 添加增强的安全基础。

在新安全模型中具有多种用户定制角色的用户。缺省角色包括读取者、发布者（读 / 写）、架构者（读 / 写 / 模式）和管理者，但是你也可添加自定义的角色，并在用户代码（例如用户定义过程）中做检查。对该模型的验证和授权需求的支持，不仅包括内建（原生）的实现和基于 LDAP/Active Directory 的实现，而且包括连接你自身安全架构（例如 Kerberos）的用户化实现。

对于原生用户的管理（创建、终止、删除），Neo4j Browser 提供了 UI 并指派了构建于一些过程之上的角色，这些过程也可用于你自身的运营工具。对于与 LDAP/Active Directory 的集成，安全模型给出了细粒度的配置 CAPA。

当前通过用户定义过程提供了数据层面的安全。这些过程允许访问数据子集，并可配置为仅对具有特定角色的用户可用。