Martin Kleppmann 所著的《设计数据密集型应用程序》一书第 188 页上的 Happens-Before 关系的版本号？

Question

我发现理解第 3 步突出显示的部分有点困难：

问题：

1. 服务器如何知道[牛奶，面粉]取代了版本号为1的[牛奶]的先前值？ [牛奶、面粉]还没有版本号，无法与版本号1进行比较。

2. 服务器如何知道[牛奶，面粉]与版本号为2的[鸡蛋]并发？ [牛奶、面粉]还没有版本号。

======================

Answer 1

我确实很难读完本章的这一部分。让我尝试解释一下。帮助我完全理解的基本理解是这些

1. 写入后不久，客户端就会进行读取
2. 如果客户端发送版本 id ，则该版本被视为依赖版本并进行更新，否则数据库中的任何现有版本都被视为并发请求。

让我们继续这些假设。

Step1：客户端 1 第一次添加

[milk]

- 数据库将其存储为 版本 1 -

[milk]

添加后，客户端进行读取。所以客户端1的本地缓存现在有

[milk]

第2步：客户端2第一次添加

[eggs]

。 - 数据库认为这是并发的，因为请求中没有版本，因此它在数据库中创建一个新版本并设置

[eggs]

。数据库现在有

Version 1 [milk]
Version 2 [eggs]

添加后，客户端 2 进行读取，数据库将两个版本发送给客户端。所以客户端 2 的本地缓存现在有

[milk]

和

[eggs]

。

第3步：客户1添加面粉。本地 cahce 客户端 1 具有来自步骤 1 的数据。因此它只有

[milk]

标记为版本 1。它向其添加面粉 --

[milk, flour]

并发送版本 1 的数据。db 将版本 1 更新为版本 3，因为版本 2 仍被视为并发。所以数据库视图是

Version 2 - [eggs]
Version 3 - [milk, flour]

添加后客户端1再次执行读取并将其本地缓存更新为

[eggs]

，

[milk, flour]

Step4：客户端 2 的最后一次读取是从步骤 2 开始的，所以它在本地缓存中的内容是

[milk]

和

[eggs]

，现在客户端 2 要添加火腿。因此它合并 3 并发送 [牛奶、鸡蛋、火腿]，服务器将版本 2 更新为版本 4。版本 3 保留，因为这被认为是并发的。所以现在的数据库视图是

Version 3 [milk, flour]
Version 4 [milk, eggs, ham]

现在客户端 2 进行读取，并将这些数据放入其本地缓存中

[milk, flour]

，

[milk, eggs, ham]

第5步：客户1想要添加培根。客户端 1 的本地缓存是第 3 步中的

[eggs]

、

[milk, flour]

。它合并了它并添加了培根，所以最后它发送

[eggs, milk, flour, bacon]

作为版本 5。第 5 步的数据库视图是

Version 4 [milk, eggs, ham]
Version 5 [milk, eggs, flour, bacon]

客户端 1 在此之后进行读取并获得最终合并的数据

[milk, eggs, flour, bacon, ham]

。 因此，如果客户 1 决定立即结帐。它将包含添加的所有项目。

我想您需要理解这里的数据流的唯一缺失的环节是我最初设置的基本理解的第 1 点。