为什么 google spanner 同时使用两阶段提交和 paxos？
Why does google spanner use both two phase commit and paxos?
我正在阅读 Google 扳手 https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf 的论文
我不清楚的一件事是实施两阶段提交和 Paxos 的选择。论文中指出，当一个事务涉及多个Paxos组时，采用两阶段提交的方式来完成事务。我的问题是为什么不对那些 Paxos 组实施两阶段提交而不是实施 Paxos？
您可以在 Spanner、TrueTime &
"What happens during a Partition" 段落中的 CAP 定理 文档。
To understand partitions, we need to know a little bit more about how Spanner works. As with most ACID
databases, Spanner uses two-phase commit (2PC) and strict two-phase locking to ensure isolation and
strong consistency. 2PC has been called the “anti-availability” protocol [Hel16] because all members must
be up for it to work. Spanner mitigates this by having each member be a Paxos group, thus ensuring each
2PC “member” is highly available even if some of its Paxos participants are down. Data is divided into
groups that form the basic unit of placement and replication.
基本上 Spanner，与大多数 ACID 数据库一样，它使用 2PC（两阶段提交），并使用 Paxos 组来减轻 "anti-availability" 的缺点。
在最高的抽象层次上，Spanner 是一个数据库，它在遍布世界各地的数据中心的多组 Paxos 状态机之间分片数据。
复制用于全球可用性和地理位置；客户
副本之间自动故障转移。当数据量或服务器数量发生变化时，Spanner 会自动跨机器重新分片数据，并且它会自动跨机器（甚至跨数据中心）迁移数据以平衡负载和响应故障。
为了支持复制，每个 spanserver 在每个 tablet 之上实现了一个 Paxos 状态机。 （早期的 Spanner 化身支持每个 tablet 多个 Paxos 状态机，这允许更灵活的复制配置。该设计的复杂性导致我们放弃它。）每个状态机存储其元数据并在其相应的 tablet。我们的 Paxos 实现支持具有基于时间的领导者租约的长期领导者，其长度默认为 10 秒。当前的 Spanner 实现记录每个 Paxos 写入两次：一次在 tablet 的日志中，一次在 Paxos 日志中。这个选择是出于权宜之计，我们最终可能会对此进行补救。
我们的 Paxos 实现是流水线的，以便在存在 WAN 延迟的情况下提高 Spanner 的吞吐量。所谓“流水线”，我们指的是 Lamport 的“多法令议会”，它既分摊了在多个法令中选举领导人的成本，又允许对不同的法令同时进行投票。值得注意的是，虽然法令可能被乱序批准，但法令是按顺序应用的。
Paxos 状态机用于实现一致复制的映射包。每个副本的键值映射状态存储在其对应的 tablet 中。写入必须在领导者处启动 Paxos 协议；在任何足够最新的副本上直接从底层 tablet 读取访问状态。副本集统称为一个 Paxos 组。
在 Bigtable 和 Spanner 中，我们都是为长期事务设计的（例如，为了报告生成，它可能承担
分钟的顺序），在存在冲突的情况下，在乐观并发控制下表现不佳。需要同步的操作，比如事务性读，获取锁中的锁table；其他操作绕过锁table。国家
锁的 table 大部分是易变的（即，不通过 Paxos 复制）：我们解释细节
在第 4.2.1 节中进一步介绍。（请注意，拥有一个长寿的 Paxos 领导者是至关重要的
有效地管理锁 table。）
在作为领导者的每个副本中，每个 spanserver 还实现了一个事务管理器来支持分布式事务。事务管理器用于实现参与者领导者；该组中的其他副本将被称为参与者奴隶。如果事务只涉及一个 Paxos 组（大多数事务都是这种情况），它可以绕过事务管理器，因为锁 table 和 Paxos 一起提供事务性。如果事务涉及多个 Paxos 组，则这些组的领导者协调执行两阶段提交。其中一个参与者组被选为协调器：该组的参与者组长将被称为协调器组长，该组的从属称为协调器从属。每个事务管理器的状态存储在底层 Paxos 组中（因此被复制）。
来源material -
Google’s Globally Distributed Database
Spanner, TrueTime & The CAP Theorem
Life of Cloud Spanner Reads & Writes
我正在阅读 Google 扳手 https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf 的论文 我不清楚的一件事是实施两阶段提交和 Paxos 的选择。论文中指出，当一个事务涉及多个Paxos组时，采用两阶段提交的方式来完成事务。我的问题是为什么不对那些 Paxos 组实施两阶段提交而不是实施 Paxos？
您可以在 Spanner、TrueTime & "What happens during a Partition" 段落中的 CAP 定理 文档。
To understand partitions, we need to know a little bit more about how Spanner works. As with most ACID databases, Spanner uses two-phase commit (2PC) and strict two-phase locking to ensure isolation and strong consistency. 2PC has been called the “anti-availability” protocol [Hel16] because all members must be up for it to work. Spanner mitigates this by having each member be a Paxos group, thus ensuring each 2PC “member” is highly available even if some of its Paxos participants are down. Data is divided into groups that form the basic unit of placement and replication.
基本上 Spanner，与大多数 ACID 数据库一样，它使用 2PC（两阶段提交），并使用 Paxos 组来减轻 "anti-availability" 的缺点。
在最高的抽象层次上，Spanner 是一个数据库，它在遍布世界各地的数据中心的多组 Paxos 状态机之间分片数据。
复制用于全球可用性和地理位置；客户 副本之间自动故障转移。当数据量或服务器数量发生变化时，Spanner 会自动跨机器重新分片数据，并且它会自动跨机器（甚至跨数据中心）迁移数据以平衡负载和响应故障。
为了支持复制，每个 spanserver 在每个 tablet 之上实现了一个 Paxos 状态机。 （早期的 Spanner 化身支持每个 tablet 多个 Paxos 状态机，这允许更灵活的复制配置。该设计的复杂性导致我们放弃它。）每个状态机存储其元数据并在其相应的 tablet。我们的 Paxos 实现支持具有基于时间的领导者租约的长期领导者，其长度默认为 10 秒。当前的 Spanner 实现记录每个 Paxos 写入两次：一次在 tablet 的日志中，一次在 Paxos 日志中。这个选择是出于权宜之计，我们最终可能会对此进行补救。
我们的 Paxos 实现是流水线的，以便在存在 WAN 延迟的情况下提高 Spanner 的吞吐量。所谓“流水线”，我们指的是 Lamport 的“多法令议会”，它既分摊了在多个法令中选举领导人的成本，又允许对不同的法令同时进行投票。值得注意的是，虽然法令可能被乱序批准，但法令是按顺序应用的。
Paxos 状态机用于实现一致复制的映射包。每个副本的键值映射状态存储在其对应的 tablet 中。写入必须在领导者处启动 Paxos 协议；在任何足够最新的副本上直接从底层 tablet 读取访问状态。副本集统称为一个 Paxos 组。
在 Bigtable 和 Spanner 中，我们都是为长期事务设计的（例如，为了报告生成，它可能承担 分钟的顺序），在存在冲突的情况下，在乐观并发控制下表现不佳。需要同步的操作，比如事务性读，获取锁中的锁table；其他操作绕过锁table。国家 锁的 table 大部分是易变的（即，不通过 Paxos 复制）：我们解释细节 在第 4.2.1 节中进一步介绍。（请注意，拥有一个长寿的 Paxos 领导者是至关重要的 有效地管理锁 table。）
在作为领导者的每个副本中，每个 spanserver 还实现了一个事务管理器来支持分布式事务。事务管理器用于实现参与者领导者；该组中的其他副本将被称为参与者奴隶。如果事务只涉及一个 Paxos 组（大多数事务都是这种情况），它可以绕过事务管理器，因为锁 table 和 Paxos 一起提供事务性。如果事务涉及多个 Paxos 组，则这些组的领导者协调执行两阶段提交。其中一个参与者组被选为协调器：该组的参与者组长将被称为协调器组长，该组的从属称为协调器从属。每个事务管理器的状态存储在底层 Paxos 组中（因此被复制）。
来源material -
Google’s Globally Distributed Database
Spanner, TrueTime & The CAP Theorem
Life of Cloud Spanner Reads & Writes