Spanner 的 TrueTime API 声称对于实现强一致性和非常高的可用性是必要的。我想知道使用 Raft 是否可以实现相同级别的一致性和可用性（没有原子钟，这对我们大多数人来说不实用）？
这个想法是通过 Raft 集群来实现每个 split（分片）。 Spanner和Raft的写协议几乎相同（由leader协调并使用锁）。在 Spanner 中，读取由副本处理。副本联系领导者以验证其最后提交时间戳是否与领导者一样更新，因此不会返回过时的数据。 Raft 也可以通过验证跟随者的最后提交日志索引是否与领导者相同来做到这一点。
我想表现会相似。我错过了什么吗？
Spanner 实际上确实使用分布式共识算法（因为Spanner早于Raft的创建，它使用Paxos，但Paxos很容易被Raft取代）。您缺少的是 Spanner 中有两层。
第一层：两阶段提交
Spanner spanservers 主机平板电脑。平板电脑是桌子的一部分。不同的tablet分布在不同的spanserver上。为了跨这些跨服务器提供通用 (ACID) 数据库事务，Spanner 使用两阶段提交、TrueTime 和锁。
底层第二层：Paxos
两阶段提交通常会带来很大的可用性问题：如果事务的一个参与者不可用，则事务必须中止。 Spanner 通过让每个参与者成为一个 Paxos 组来解决这个问题，因此每个参与者的数据使用分布式共识协议在多台机器之间复制。
Paxos/Raft 和两阶段提交的区别
现在让我引用 麻省理工学院的分布式系统讲座：
返回扳手问：可以使用 Raft 代替两阶段提交吗？
A：两阶段提交和Raft解决不同的问题。
两阶段提交导致不同的计算机做不同的事情 （例如，爱丽丝的银行借记爱丽丝，鲍勃的银行贷记鲍勃），并导致 他们“全部”做自己的事情，或者都不做。两阶段提交 如果某些情况，系统通常不可用（无法取得进展） 无法联系到参与者，因为他们必须等待所有人 参与计算机执行其交易部分。 Raft 导致大多数同级都做
相同的事情（所以 它们仍然是复制品）。 Raft 只需等待多数就可以了， 由于对等点是副本，因此我们可以使系统 面对失败时可用。
使用 Raft 让 Alice 向 Bob 转账只有在所有 Raft 节点都保持相应的状态（Alice 的广告 Bob 的账户余额）的情况下才有效。然而，如果Alice的余额由节点A维护，Bob的余额由节点B维护，那么仅靠Raft就无法保证交易性。这是因为，在提交交易之前，我们需要确保Alice和Bob的账户存在，并且Alice的余额足以进行转账。节点 A 和节点 B 都无法自行计算出这些必要的信息。
Spanner 在 Spanserver 保持相同状态的情况下使用 Paxos（同样，它也可以使用 Raft）：复制单个数据片（即共享状态）的 Spanserver 形成该数据片的 Paxos 组。然而，单独的 Paxos 或 Raft 无法在维护不同状态的不同 spanserver 之间提供 ACID 属性。 Spanner 使用两阶段提交来保证原子性，使用 TrueTime 来保证隔离性。
Raft 用于全局序列化我想你可以使用 Raft 而不是 TrueTime （但仍然与两阶段提交一起！）来就全局事务序列达成一致。在这种情况下，两阶段提交将提供原子性，而通过 Raft 的序列化将简单地提供隔离。然而，对所有数据库事务强制执行全局顺序将带来不必要的限制。大多数交易都可以很好地并行执行。