XeLabs/ddia
2
0
Fork 0
mirror of https://github.com/Vonng/ddia.git synced 2026-06-25 19:06:55 +08:00
Code Issues Projects Releases Wiki Activity

fixed zh-cn translation of "the battle cry"

Browse source
This commit is contained in:
Komoriii 2020-11-18 19:47:33 +08:00 committed by GitHub
parent 1bf5a38bdc
commit 2f06ea27c1
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
ch5.md
View file

@ -193,7 +193,7 @@
​ 不幸的是，当应用程序从异步从库读取时，如果从库落后，它可能会看到过时的信息。这会导致数据库中出现明显的不一致：同时对主库和从库执行相同的查询，可能得到不同的结果，因为并非所有的写入都反映在从库中。这种不一致只是一个暂时的状态——如果停止写入数据库并等待一段时间，从库最终会赶上并与主库保持一致。出于这个原因，这种效应被称为 **最终一致性（eventually consistency）**[^iii]【22,23】
[^iii]: 道格拉斯·特里（Douglas Terry）等人创造了术语最终一致性。 【24】 并经由Werner Vogels 【22】推广，成为许多NoSQL项目的战吼。 然而，不只有NoSQL数据库是最终一致的：关系型数据库中的异步复制追随者也有相同的特性。
[^iii]: 道格拉斯·特里（Douglas Terry）等人创造了术语最终一致性。 【24】 并经由Werner Vogels 【22】推广，成为许多NoSQL项目的标语。 然而，不只有NoSQL数据库是最终一致的：关系型数据库中的异步复制追随者也有相同的特性。
​ “最终”一词故意含糊不清：总的来说，副本落后的程度是没有限制的。在正常的操作中，**复制延迟（replication lag）**，即写入主库到反映至从库之间的延迟，可能仅仅是几分之一秒，在实践中并不显眼。但如果系统在接近极限的情况下运行，或网络中存在问题，延迟可以轻而易举地超过几秒，甚至几分钟。