lee*_*269 2 google-cloud-spanner
我正在阅读 Google 扳手https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf的论文， 我不清楚的一件事是实施的选择两阶段提交和Paxos。论文指出，当一个事务涉及多个Paxos组时，使用两阶段提交来完成事务。我的问题是为什么不在这些 Paxos 组上实施两阶段提交而不是实施 Paxos？
您可以在Spanner、TrueTime 和 CAP 定理文档的“分区期间会发生什么”段落中找到更多详细信息和问题的答案。
要了解分区，我们需要更多地了解 Spanner 的工作原理。与大多数 ACID 数据库一样，Spanner 使用两阶段提交 (2PC) 和严格的两阶段锁定来确保隔离和强一致性。2PC 被称为“反可用性”协议 [Hel16]，因为所有成员都必须为它的工作做好准备。Spanner 通过让每个成员成为一个 Paxos 组来缓解这种情况，从而确保每个 2PC“成员”即使在其某些 Paxos 参与者宕机的情况下也是高度可用的。数据被分成构成放置和复制基本单元的组。
基本上 Spanner 与大多数 ACID 数据库一样，它使用 2PC（两阶段提交），并使用 Paxos 组来减轻“抗可用性”的缺点。
在最高抽象级别上，Spanner 是一个数据库，可将数据分片到遍布世界各地的数据中心的多组 Paxos 状态机中。
\n\n复制用于全球可用性和地理位置；客户端\n在副本之间自动进行故障转移。随着数据量或服务器数量的变化，Spanner 自动跨机器重新分片数据，并自动跨机器（甚至跨数据中心）迁移数据以平衡负载并响应故障。
\n\n为了支持复制，每个spanserver在每个tablet之上实现一个Paxos状态机。（早期的 Spanner 版本支持每个 Tablet 多个 Paxos 状态机，这允许更灵活的复制配置。该设计的复杂性导致我们放弃了它。）每个状态机都将其元数据和日志存储在其相应的 Tablet 中。我们的 Paxos 实现通过基于时间的领导者租约支持长期领导者，其长度默认为 10 秒。当前的 Spanner 实现将每次 Paxos 写入记录两次：一次在tablet\xe2\x80\x99s 日志中，一次在 Paxos 日志中。这个选择是出于权宜之计，我们最终可能会纠正这个问题。
\n\n我们的 Paxos 实现是管道化的，以便在存在 WAN 延迟的情况下提高 Spanner\xe2\x80\x99s 的吞吐量。\xe2\x80\x9cpipelined、\xe2\x80\x9d 是指 Lamport\xe2\x80\x99s \xe2\x80\x9c 多法令议会\xe2\x80\x9d，这两者都分摊了跨多个选举领导者的成本法令并允许对不同法令同时进行投票。需要注意的是，虽然法令的批准可能是无序的，但法令是按顺序实施的。
\n\nPaxos 状态机用于实现一致复制的映射包。每个副本的键值映射状态存储在其对应的tablet中。写入必须在leader处启动Paxos协议；直接从任何足够最新的副本上的底层平板电脑读取访问状态。副本集统称为 Paxos 组。
\n\n在 Bigtable 和 Spanner 中，我们都是针对长期事务进行设计的（例如，生成报告，这可能需要几分钟的时间），在存在冲突的乐观并发控制下，这些事务的性能很差。需要同步的操作，例如事务性读取，会获取锁表中的锁；其他操作绕过锁表。锁表的状态\n大多是易失性的（即，不通过 Paxos 复制）：我们在第 4.2.1 节中\n进一步解释详细信息。（请注意，拥有一个长期存在的 Paxos 领导者对于有效管理锁表至关重要\n .)
\n\n在作为领导者的每个副本中，每个 spanserver 还实现一个事务管理器来支持分布式事务。事务管理器用于实现参与者领导者；该组中的其他副本将被称为参与者从属副本。如果一笔事务仅涉及一个 Paxos 组（大多数事务都是这种情况），则它可以绕过事务管理器，因为锁表和 Paxos 一起提供事务性。如果一笔事务涉及多个 Paxos 组，则这些组\xe2\x80\x99 领导者协调执行两阶段提交。选择一个参与者组作为协调者：该组的参与者领导者将被称为协调者领导者，该组的从者将被称为协调者从者。每个事务管理器的状态都存储在底层 Paxos 组中（因此会被复制）。
\n\n来源材料-
\n\n\n\n\n\n\n\n\n\n\n| 归档时间： |
|
| 查看次数： |
1493 次 |
| 最近记录： |