在Spanner: Google’s Globally-Distributed Database第2.1节中，我们读到：
为了支持复制，每个spanserver在每个平板电脑上实现一个Paxos状态机。 （早期的Spanner化身支持每个平板电脑的多个Paxos状态机，这允许更灵活的复制配置。该设计的复杂性导致我们放弃它。）
Paxos状态机用于实现一致复制的映射包。
这个单一的Paxos状态机是否类似于＆＃34; Paxos Made Simple＆＃34;提到Paxos状态机？
我很好奇一位新领导人选择了如何学习所有丢失的数据。任何人都可以在Spanner中描述Paxos组的详细实现吗？
答案 0 :(得分：1)
由于Spanner使用同步复制，因此没有数据丢失。领导者没有任何状态，如果他们失败或无法获得，则需要转移。最糟糕的情况是，事务可能需要重试或失败，例如在扩展分区期间。由于Spanner构建在其上的底层基础设施（其属性源自软件和硬件的结合），这样的分区非常罕见。
领导者通常有10秒钟的租约，如果他们证明是健康的话，这些租约会被延长，这意味着领导者每隔10秒就会被选中一次。
答案 1 :(得分：1)
Google Cloud Platform上的Cloud Spanner与白皮书中的Spanner相同，它提供了有关其自定义Paxos实施的更多详细信息。 CAP定理的作者Eric Brewer写了一篇关于它的白皮书：
https://research.google.com/pubs/pub45855.html
==
要了解分区，我们需要更多地了解Spanner的工作原理。与大多数ACID一样 数据库，Spanner使用两阶段提交（2PC）和严格的两阶段锁定来确保隔离和 一致性强。 2PC被称为“反可用性”协议[Hel16]，因为所有成员都必须 努力工作。 Spanner通过让每个成员成为Paxos组来减轻这种情况，从而确保每个成员 即使一些Paxos参与者失败，2PC“会员”也很有用。数据分为 组成基本的放置和复制单元的组。
==
答案 2 :(得分：0)
复制更改的常用算法如下：
单一领导者复制： 最常见的复制拓扑是拥有一个领导者，然后将更改复制到所有关注者。
每个副本都需要处理对数据库的每次写入;否则，副本将不再包含相同的数据。最常见的解决方案称为基于领导的复制（也称为主动/被动或主从复制）。
更深入的解释： http://writeulearn.com/replication-distributed-data/