在Spanner:谷歌的全球分布式数据库，第2.1节中，我们读到：
为了支持复制，每个spanserver在每个平板电脑上实现一个Paxos状态机。（早期的Spanner版本支持每个平板电脑有多个Paxos状态机，这允许更灵活的复制配置。这种设计的复杂性导致我们放弃了它。）
Paxos状态机用于实现一致复制的映射包。
这个单一的Paxos状态机是否类似于"Paxos Made Simple"提到的Paxos状态机？
我很好奇一旦一位新领导人当选，如何学习所有丢失的数据。有人可以描述Spanner中Paxos组的详细实现吗？
由于Spanner使用同步复制，因此不会丢失任何数据。如果领导人失败或变得不可用，他们就没有需要转移的状态。最糟糕的情况是，事务可能需要重试或失败，例如在扩展分区期间。由于Spanner构建在底层基础设施之上（其属性源自软件和硬件的联合），这样的分区非常罕见。
领导人通常有10秒的租约，如果他们证明健康，就会延长租约，这意味着领导人每10秒就会连任一次。
谷歌云平台上的云扳手与白皮书中的扳手相同，它提供了有关其自定义Paxos实现的更多细节。CAP定理的作者Eric Brewer写了一篇关于它的白皮书：
https://research.google.com/pubs/pub45855.html
===
为了理解分区，我们需要更多地了解Spanner是如何工作的。与大多数ACID一样数据库，Spanner使用两阶段提交（2PC）和严格的两阶段锁定来确保隔离和一致性强。2PC被称为"反可用性"协议[Hel16]，因为所有成员都必须准备好让它发挥作用。Spanner通过让每个成员都是Paxos组来缓解这种情况，从而确保每个成员2PC"会员"是高度可用的，即使它的一些Paxos参与者已经倒下。数据分为构成放置和复制基本单元的组。
==