在 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 用一个代码例子展示了书签模式，强调了在他看来，实现书签模式是非常简单的。在这个例子中，客户端接收一个事务标识，然后传递给此后的查询。
评论