Merge pull request #140 from Bowser1704/master

修复第五章的一些翻译问题
This commit is contained in:
Gang Yin 2021-11-01 18:36:50 +08:00 committed by GitHub
commit 90a76f3def
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

10
ch5.md
View File

@ -739,11 +739,11 @@
***可伸缩性***
能够处理比单个机器更高的读取量可以通过对副本进行读取来处理
通过在副本上读,能够处理比单机更大的读取量
尽管是一个简单的目标 - 在几台机器上保留相同数据的副本,但复制却是一个非常棘手的问题。它需要仔细考虑并发和所有可能出错的事情,并处理这些故障的后果。至少,我们需要处理不可用的节点和网络中断(甚至不考虑更隐蔽的故障,例如由于软件错误导致的静默数据损坏)。
尽管是一个简单的目标 - 在几台机器上保留相同数据的副本,但复制却是一个非常棘手的问题。它需要仔细考虑并发和所有可能出错的事情,并处理这些故障的后果。至少,我们需要处理不可用的节点和网络中断(这还不包括更隐蔽的故障,例如由于软件错误导致的静默数据损坏)。
我们讨论了复制的三种主要方法:
@ -761,7 +761,7 @@
每种方法都有优点和缺点。单主复制是非常流行的,因为它很容易理解,不需要担心冲突解决。在出现故障节点,网络中断和延迟峰值的情况下,多领导者和无领导者复制可以更加稳健,但以更难以推理并仅提供非常弱的一致性保证为代价。
复制可以是同步的,也可以是异步的,这在发生故障时对系统行为有深远的影响。尽管在系统运行平稳时异步复制速度很快,但是在复制滞后增加和服务器故障时要弄清楚会发生什么,这一点很重要。如果一个领导者失败了,并且你提升了一个异步更新的追随者成为新的领导者,那么最近提交的数据可能会丢失。
复制可以是同步的,也可以是异步的,这在发生故障时对系统行为有深远的影响。尽管在系统运行平稳时异步复制速度很快,但是要弄清楚在复制滞后增加和服务器故障时会发生什么,这一点很重要。如果一个领导者失败了,并且你提升了一个异步更新的追随者成为新的领导者,那么最近提交的数据可能会丢失。
我们研究了一些可能由复制滞后引起的奇怪效应,我们也讨论了一些有助于决定应用程序在复制滞后时的行为的一致性模型:
@ -771,11 +771,11 @@
***单调读***
用户在一个时间点看到数据后,他们不应该在某个更早的时间点看到数据。
用户在看到某一个时间点的数据后,他们不应该再看到某个更早时间点的数据。
***一致前缀读***
用户应该将数据视为具有因果意义的状态:例如,按照正确的顺序查看问题及其答复
用户应该看到数据处于一种具有因果意义的状态:例如,按正确的顺序看到一个问题和对应的回答