CockroachDB 两阶段提交有阻塞还是无阻塞？

Question

两阶段提交应该会遇到阻塞问题。 CockroachDB 是这种情况吗？如果不是，如何避免？

Answer 1

总结:两阶段提交是阻塞的，因此保持两阶段提交的内容尽可能“小”非常重要，以便所有操作的集合阻塞是最小的。 CockroachDB 使用具有意图的 MVCC 来实现此目的，仅针对单个意图进行两阶段提交。由于 CockroachDB 提供可序列化事务，因此它会重新排序事务时间戳，以最大限度地减少绝对必要时的阻塞。

更长的答案

2-phase commits在第一阶段之后阻塞，而所有参与者都在等待协调者的回复以决定是否提交或中止第二阶段。在此期间，已经发出"is"票的参与者不能单方面撤销他们的投票，但也不能将其视为已提交(因为协调员可能会中止)。因此他们被迫阻止所有需要具体了解该交易状态的后续操作。上面这句话的关键在于“需要”:我们有责任设计我们的系统，将这一设置减少到最低限度。 CockroachDB 使用写入意图和[MVCC]来最小化这些依赖性。

考虑分布式(多键)事务键值存储的简单实现:我希望以事务方式提交一些写入事务 t1 。 t1跨越许多机器上的许多键，但特别值得关注的是它写 k1 = v2 。 k1在机器上 m1 (假设 k1=v1 是之前的值)。

自 t1跨越许多机器上的许多键，所有这些都参与两阶段提交事务。一旦两阶段事务开始，我们必须注意，我们打算写入 k1=v2 ，并且事务的状态未知(事务可能会中止，因为其他写入之一无法继续)。

现在如果有其他交易 t2出现它想要读取 k1 的值，在我们知道两阶段提交的最终结果之前，我们根本无法给该事务一个权威的答案。 t2已被阻止。

但是，我们(和 CockroachDB)可以做得更好。我们可以为每个键保留值的多个版本，并有一个并发控制机制来保持所有这些版本的顺序。也就是说，我们可以分配我们的事务时间戳，并使我们的写入看起来(松散地)如下:

`k1 = v1 committed at time=1`
`k1 = v2 at time=110 INTENT (pending transaction t1)`

现在，当 t2出现后，它有一个选项:它可以选择在time<=109处进行读取。 ，不会在 t1 上被阻止。当然，有些事务无法做到这一点(如果说，它们也是分布式的，并且有一个不同的组件只需要更高的时间戳)。这些交易将被阻止。但实际上，这可以释放数据库来分配时间戳，以便许多类型的事务可以继续进行。

正如另一个答案所说，Cockroach Labs 有一篇关于 CockroachDB 使用 MVCC 的帖子 here ，其中还解释了一些进一步的细节。