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