CockroachDB读取事务

Question

我一直在阅读谷歌斯皮纳和CockroachDB实现的只读无锁事务。两者都声称是通过使用系统时钟以无锁的方式实现的.在讨论这个问题之前，我的理解是(如果您知道这两个系统中的机器，或者仅仅在CockroachDB中)，请跳过下面一节：

• 扳手的方法更简单--在提交一个写事务之前，斯皮纳在所有涉及的碎片中选择最大时间戳作为提交时间戳，在从它的写事务返回之前，为最大时钟错误添加一个等待，称为提交等待。这意味着所有与因果相关的事务(读和写)的时间戳值都高于上一次写入的提交时间戳。对于读取事务，我们选择服务节点上的最新时间戳。例如，如果在时间戳5处提交了写入，而最大时钟错误为2，则未来的写入和只读事务将至少具有7的时间戳。
• 另一方面，CockroachDB会做一些更复杂的事情。在写时，它会在所有涉及的碎片中选择最高的时间戳，但不会等待。在读取时，它将一个初步读取时间戳指定为服务节点上的当前时间戳，然后乐观地进行遍历所有碎片的读取，如果任何碎片上的任何键都报告了可能意味着写入是否先于读取事务的写入时间戳，则重新启动读事务。它假设带有写入时间戳的键小于读取事务的时间戳，或者出现在读取事务之前，或者与其并发。不确定性机制在时间戳上的作用高于读取事务时间戳。例如，如果在时间戳8处提交了一个写，并且指定了一个读取事务，那么我们不确定该写是在读取之前还是之后，所以我们使用读取时间戳8重新启动读取事务。

相关来源- https://www.cockroachlabs.com/blog/living-without-atomic-clocks/和https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf

考虑到此实现，CockroachDB是否保证以下两个事务不会出现串行化冲突？

1. 用户阻止另一个用户，然后发布一条消息，表示他们不希望被阻塞的用户将其视为一个写事务。
2. 被阻塞的用户将其好友列表和帖子作为一个读取事务加载。

例如，考虑到好友列表和帖子生活在不同的碎片上。然后发生以下排序(假设最大时钟错误为2)

1. 最初的帖子和好友名单是在时间戳5上提交的。
2. 读取事务从时间戳7开始，它读取好友列表，它认为它在时间戳5处提交了好友列表。
3. 然后，用于阻塞朋友和发布帖子的写事务将在6点提交。
4. read事务读取posts，它认为posts是在时间戳6时提交的。

现在，事务违反了序列化性，因为读取事务在同一事务中看到了旧写和新写。

我遗漏了什么？

Answer 1

CockroachDB使用一种名为时间戳缓存的机制来处理这个问题(这是一个不幸的名称；它不是很大的缓存)。

在本例中，在第二步，当事务在时间戳7处读取好友列表时，持有好友列表的碎片记住它在t=7 (读取事务请求的时间戳，而不是存在的数据的最后修改的时间戳)上为该数据提供了读取，并且它不再允许使用较低的时间戳提交任何写入。

然后，在第三步中，当写入事务试图在t=6上写入和提交时，将检测到此冲突，并将写入事务的时间戳推送到t=8或更高版本。然后，该事务必须刷新其读取，以查看它是否可以按t=8处的情况提交。如果不能，则可能会返回错误，并且必须从一开始就重新尝试事务。

在第四步中，读取事务完成，看到在t=7中存在的数据的一致快照，而写入事务的两个部分在t=8中“在未来”。