Update ch5.md

This commit is contained in:
songzhibin97 2022-04-25 12:10:08 +08:00 committed by GitHub
parent 488e08777d
commit 0f0d23c02b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

2
ch5.md
View File

@ -618,7 +618,7 @@ Dynamo 风格的数据库允许多个客户端同时写入相同的 Key这意
实现最终融合的一种方法是声明每个副本只需要存储最 **“最近”** 的值,并允许 **“更旧”** 的值被覆盖和抛弃。然后,只要我们有一种明确的方式来确定哪个写是 “最近的”,并且每个写入最终都被复制到每个副本,那么复制最终会收敛到相同的值。
正如 **“最近”** 的引号所表明的,这个想法其实颇具误导性。在 [图 5-12](img/fig5-12.png) 的例子中,当客户端向数据库节点发送写入请求时,两个客户端都不知道另一个客户端,因此不清楚哪一个先发生了。事实上,说这两种情况都是先发生是没有意义的:我们说写入是 **并发concurrent** 的,所以它们的顺序是不确定的。
正如 **“最近”** 的引号所表明的,这个想法其实颇具误导性。在 [图 5-12](img/fig5-12.png) 的例子中,当客户端向数据库节点发送写入请求时,两个客户端都不知道另一个客户端,因此不清楚哪一个先发送请求。事实上,说这两种情况谁先发送请求是没有意义的:我们说写入是 **并发concurrent** 的,所以它们的顺序是不确定的。
即使写入没有自然的排序,我们也可以强制任意排序。例如,可以为每个写入附加一个时间戳,挑选最 **“最近”** 的最大时间戳,并丢弃具有较早时间戳的任何写入。这种冲突解决算法被称为 **最后写入胜利LWW, last write wins**,是 Cassandra 【53】唯一支持的冲突解决方法也是 Riak 【35】中的一个可选特征。