事务很难，分布式事务更难，WAN上的分布式事务是最终的老板硬度。- 安迪帕夫洛
FaunaDB是一个分布式数据库平台，支持可序列化，外部一致（也称为严格可序列化）事务。与Google Spanner或类似系统不同，FaunaDB不依赖物理时钟同步来保持一致性。此外，与Google Percolator，FoundationDB或类似系统不同，FaunaDB不会对副本距离施加任何限制，并且在全球互联网延迟时部署是实用的。
这篇文章描述了如何在FaunaDB中实现事务。我们将从一些背景开始，然后解释核心协议如何保持跨地理距离的一致性。然后，我们讨论FaunaDB架构的性能影响。
背景
FaunaDB更具体地说是一个Relational NoSQL数据库平台。术语“NoSQL”仅指接口; FaunaDB目前支持执行透明的过程接口，而不是声明性SQL。
术语“关系”指的是数据模型，但FaunaDB除支持关系外还支持图形和文档模型。它还调用了RDBMS的惯例保证：
具有可序列化隔离的ACID事务
跨副本的可线性化，一致的操作
与传统的RDBMS不同，FaunaDB即使在地理上分布也能保持这些保证。
可序列化隔离
可序列化隔离意味着系统可以并行处理许多事务，但最终结果相当于一个接一个地处理它们。对于大多数数据库系统，订单不是事先确定的。相反，事务是并行运行的，并且一些锁定变体用于确保最终结果等同于某些串行顺序。
FaunaDB中的预处理
FaunaDB的协议受到Calvin的启发，在执行对数据库的任何写入之前决定此序列顺序。对于每批并行事务，它们被插入到分布式预写事务日志中，并且FaunaDB执行引擎确保处理此批事务的顺序等同于它们出现在这个预先生成的日志中顺序。
日志中的每个事务都与实际时间相关联。但是，与其他分布式数据库不同，物理实时不是FaunaDB协议的核心组件，FaunaDB不依赖于跨服务器的时钟全局同步。“FaunaDB时间”与实时之间的粗略对应仅仅是开发人员的事情，但不是自身操作约束。相反，“之前”和“之后”的概念完全取决于事务在分布式日志中出现的顺序。
FaunaDB可以从分布式日志中的任何一点获取“快照”，其中包括在该点之前出现在日志中的所有事务的写入，并且在此之后则不会写入。例如，T4处的快照将包含事务T0-T4，但不包括之后的。
为了在日志中的任意点快速生成快照，FaunaDB会保留每个记录的多个版本。每个版本都使用timestamp进行注释 - 时间戳。
客户端可以将事务发送到任何复制节点 - 包括只读事务和更新数据库中数据的事务。但是，整个FaunaDB部署只有一个事务日志(banq注：类似区块链哦)。复制节点必须就如何将新事务插入日志达成共识，FaunaDB使用优化的Raft实现来达成共识。