皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

大规模 Neo4j 集群中的因果一致性

作者 Andrew Morgan ,译者 Rays

在 QCon 2017 伦敦大会上,Neo4J Technology 首席科学家 Jim Webber 介绍了 Neo4J 是如何实现 因果一致性 的。他的演讲内容包括:高层概览 Neo4J 集群的架构、使用 Raft 实现共识机制,以及用于实现“写后读”(RAW,read-after-write)一致性的“书签”(Bookmarking)模式。

据 Webber 介绍,为将集群问题分而治之,Neo4J 提供了两类角色不同的节点,分别称为核心(Core)节点和只读(Read)节点。在集群中,核心节点用于写操作,并提供了集群的持久性保证。只读节点是核心集群的只读异步副本,实现在“多读少写”(Read-heavy)负载场景下的扩展。

,Webber 进一步介绍了为达成持久性保证,核心节点是如何实现 Raft 共识算法的。一旦一个事务写入到一个核心节点,Raft 就会对事务做日志,并将事务到复制到集群中所有其余的核心节点。Raft 并非等待事务被完全复制,而是等待大多数选举(Majority Vote),这足以保证写操作的持久性。

Webb 还介绍了 Raft 在性能上和弹性上的优点。对于性能而言,Raft 只需等待大多数复制,因此阻塞的时间更短,进而降低了查询延迟。从弹性的角度看,即使一些节点故障,只要大多数依然可以选举,核心集群就仍然正常工作。

Webber 对 Raft 和 Paxos 做了比较,Raft 相对更简单,而且更易于实现,这就是 Neo4J 选择 Raft 的原因。他认为 Raft 降低了软件故障出现的可能性,提高了应用的可维护性。

据 Webber 介绍,图数据库通常是一类“多读少写”的数据库。即使在写操作期间,也必须读取和遍历图数据。这就是在 Neo4J 集群中通常只读节点要多于核心节点的原因。因为只读节点不参与共识提交,这意味着只读节点适用于自动扩展,并且更易于按需部署或调配。

考虑到事务是被异步复制到只读节点的,Webber 给出了一个简单应用场景,对此机制进行了展示。如果用户需要在创建数据后就立刻读取它们,即便写操作具有持久性保证,但还是有可能无法发现这些数据。这是由于数据是最终一致的,可能数据尚未复制到被查询的节点上。

要解决这一“写后读”一致性问题,Webber 介绍了 Neo4J 中提供的一种因果一致性模式,称为“书签”。

书签模式的第一阶段包含一次写操作,写操作完成后将返回相应的事务标识给客户端。第二阶段是一次读操作,客户端在查询中发送事务的标识。通过使用事务标识,被读取的节点将可以阻塞给定的事务。

Webber 用一个代码例子展示了书签模式,强调了在他看来,实现书签模式是非常简单的。在这个例子中,客户端接收一个事务标识,然后传递给此后的查询。

要了解更多的细节,可以从 此处 在线完整观看该演讲。Webber 还推荐阅读一下 Raft 的 论文

查看英文原文: Causal Consistency for Large Neo4j Clusters

转自 http://www.infoq.com/cn/news/2017/04/causal-consistency-neo4j

分享到:更多 ()