Merge pull request #59 from AlexanderMisel/patch-1

呼叫->调用,显着->显著
This commit is contained in:
Feng Ruohang 2019-12-13 22:55:38 +08:00 committed by GitHub
commit 583167dfc1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
7 changed files with 10 additions and 10 deletions

2
ch1.md
View File

@ -247,7 +247,7 @@
> #### 实践中的百分位点
>
> 在多重调用的后端服务里,高百分位数变得特别重要。即使并行调用,最终用户请求仍然需要等待最慢的并行呼叫完成。如[图1-5](img/fig1-5.png)所示,只需要一个缓慢的呼叫就可以使整个最终用户请求变慢。即使只有一小部分后端呼叫速度较慢如果最终用户请求需要多个后端调用则获得较慢调用的机会也会增加因此较高比例的最终用户请求速度会变慢效果称为尾部延迟放大【24】
> 在多重调用的后端服务里,高百分位数变得特别重要。即使并行调用,最终用户请求仍然需要等待最慢的并行调用完成。如[图1-5](img/fig1-5.png)所示,只需要一个缓慢的调用就可以使整个最终用户请求变慢。即使只有一小部分后端调用速度较慢如果最终用户请求需要多个后端调用则获得较慢调用的机会也会增加因此较高比例的最终用户请求速度会变慢效果称为尾部延迟放大【24】
>
> 如果您想将响应时间百分点添加到您的服务的监视仪表板则需要持续有效地计算它们。例如您可能希望在最近10分钟内保持请求响应时间的滚动窗口。每一分钟您都会计算出该窗口中的中值和各种百分数并将这些度量值绘制在图上。
>

View File

@ -646,7 +646,7 @@ top5.each{|count, url| puts "#{count} #{url}" } # 5
由于编程模型一次仅处理一个顶点(有时称为“像顶点一样思考”),所以框架可以以任意方式对图分区。理想情况下如果顶点需要进行大量的通信,那么它们最好能被分区到同一台机器上。然而找到这样一种优化的分区方法是很困难的 —— 在实践中图经常按照任意分配的顶点ID分区而不会尝试将相关的顶点分组在一起。
因此,图算法通常会有很多跨机器通信的额外开销,而中间状态(节点之间发送的消息)往往比原始图大。通过网络发送消息的开销会显拖慢分布式图算法的速度。
因此,图算法通常会有很多跨机器通信的额外开销,而中间状态(节点之间发送的消息)往往比原始图大。通过网络发送消息的开销会显拖慢分布式图算法的速度。
出于这个原因如果你的图可以放入一台计算机的内存中那么单机甚至可能是单线程算法很可能会超越分布式批处理【73,74】。图比内存大也没关系只要能放入单台计算机的磁盘使用GraphChi等框架进行单机处理是就一个可行的选择【75】。如果图太大不适合单机处理那么像Pregel这样的分布式方法是不可避免的。高效的并行图算法是一个进行中的研究领域【76】。

4
ch3.md
View File

@ -345,7 +345,7 @@ SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.5079
#### 在内存中存储一切
本章到目前为止讨论的数据结构都是对磁盘限制的回答。与主内存相比磁盘处理起来很尴尬。对于磁盘和SSD如果要在读取和写入时获得良好性能则需要仔细地布置磁盘上的数据。但是我们容忍这种尴尬因为磁盘有两个显的优点它们是耐用的它们的内容在电源关闭时不会丢失并且每GB的成本比RAM低。
本章到目前为止讨论的数据结构都是对磁盘限制的回答。与主内存相比磁盘处理起来很尴尬。对于磁盘和SSD如果要在读取和写入时获得良好性能则需要仔细地布置磁盘上的数据。但是我们容忍这种尴尬因为磁盘有两个显的优点它们是耐用的它们的内容在电源关闭时不会丢失并且每GB的成本比RAM低。
随着RAM变得更便宜每GB的成本价格被侵蚀了。许多数据集不是那么大所以将它们全部保存在内存中是非常可行的可能分布在多个机器上。这导致了内存数据库的发展。
@ -560,7 +560,7 @@ WHERE product_sk = 31 AND store_sk = 3
### 聚合:数据立方体和物化视图
并不是每个数据仓库都必定是一个列存储:传统的面向行的数据库和其他一些架构也被使用。然而,对于专门的分析查询,列式存储可以显加快所以它正在迅速普及【51,63】。
并不是每个数据仓库都必定是一个列存储:传统的面向行的数据库和其他一些架构也被使用。然而,对于专门的分析查询,列式存储可以显加快所以它正在迅速普及【51,63】。
数据仓库的另一个值得一提的是物化汇总。如前所述数据仓库查询通常涉及一个聚合函数如SQL中的COUNTSUMAVGMIN或MAX。如果相同的聚合被许多不同的查询使用那么每次都可以通过原始数据来处理。为什么不缓存一些查询使用最频繁的计数或总和

2
ch4.md
View File

@ -432,7 +432,7 @@ Web服务仅仅是通过网络进行API请求的一系列技术的最新版本
其中一些框架还提供服务发现即允许客户端找出在哪个IP地址和端口号上可以找到特定的服务。我们将在“[请求路由](ch6.md#请求路由)”中回到这个主题。
使用二进制编码格式的自定义RPC协议可以实现比通用的JSON over REST更好的性能。但是RESTful API还有其他一些显的优点对于实验和调试只需使用Web浏览器或命令行工具curl无需任何代码生成或软件安装即可向其请求它是受支持的所有的主流编程语言和平台还有大量可用的工具服务器缓存负载平衡器代理防火墙监控调试工具测试工具等的生态系统。由于这些原因REST似乎是公共API的主要风格。 RPC框架的主要重点在于同一组织拥有的服务之间的请求通常在同一数据中心内。
使用二进制编码格式的自定义RPC协议可以实现比通用的JSON over REST更好的性能。但是RESTful API还有其他一些显的优点对于实验和调试只需使用Web浏览器或命令行工具curl无需任何代码生成或软件安装即可向其请求它是受支持的所有的主流编程语言和平台还有大量可用的工具服务器缓存负载平衡器代理防火墙监控调试工具测试工具等的生态系统。由于这些原因REST似乎是公共API的主要风格。 RPC框架的主要重点在于同一组织拥有的服务之间的请求通常在同一数据中心内。
#### 数据编码与RPC的演化

6
ch5.md
View File

@ -54,7 +54,7 @@
在[图5-2]()的示例中从库1的复制是同步的在向用户报告写入成功并使结果对其他用户可见之前主库需要等待从库1的确认确保从库1已经收到写入操作。以及在使写入对其他客户端可见之前接收到写入。跟随者2的复制是异步的主库发送消息但不等待从库的响应。
在这幅图中从库2处理消息前存在一个显的延迟。通常情况下,复制的速度相当快:大多数数据库系统能在一秒向从库应用变更,但它们不能提供复制用时的保证。有些情况下,从库可能落后主库几分钟或更久;例如:从库正在从故障中恢复,系统在最大容量附近运行,或者如果节点间存在网络问题。
在这幅图中从库2处理消息前存在一个显的延迟。通常情况下,复制的速度相当快:大多数数据库系统能在一秒向从库应用变更,但它们不能提供复制用时的保证。有些情况下,从库可能落后主库几分钟或更久;例如:从库正在从故障中恢复,系统在最大容量附近运行,或者如果节点间存在网络问题。
同步复制的优点是,从库保证有与主库一致的最新数据副本。如果主库突然失效,我们可以确信这些数据仍然能在从库上上找到。缺点是,如果同步从库没有响应(比如它已经崩溃,或者出现网络故障,或其它任何原因),主库就无法处理写入操作。主库必须阻止所有写入,并等待同步副本再次可用。
@ -507,7 +507,7 @@
***反熵过程Anti-entropy process***
此外,一些数据存储具有后台进程,该进程不断查找副本之间的数据差异,并将任何缺少的数据从一个副本复制到另一个副本。与基于领导者的复制中的复制日志不同,此反熵过程不会以任何特定的顺序复制写入,并且在复制数据之前可能会有显的延迟。
此外,一些数据存储具有后台进程,该进程不断查找副本之间的数据差异,并将任何缺少的数据从一个副本复制到另一个副本。与基于领导者的复制中的复制日志不同,此反熵过程不会以任何特定的顺序复制写入,并且在复制数据之前可能会有显的延迟。
并不是所有的系统都实现了这两个;例如Voldemort目前没有反熵过程。请注意如果没有反熵过程某些副本中很少读取的值可能会丢失从而降低了持久性因为只有在应用程序读取值时才执行读修复。
@ -567,7 +567,7 @@
#### 监控陈旧度
从运维的角度来看,监视你的数据库是否返回最新的结果是很重要的。即使应用可以容忍陈旧的读取,您也需要了解复制的健康状况。如果显落后,应该提醒您,以便您可以调查原因(例如,网络中的问题或超载节点)。
从运维的角度来看,监视你的数据库是否返回最新的结果是很重要的。即使应用可以容忍陈旧的读取,您也需要了解复制的健康状况。如果显落后,应该提醒您,以便您可以调查原因(例如,网络中的问题或超载节点)。
对于基于领导者的复制,数据库通常会公开复制滞后的度量标准,您可以将其提供给监视系统。这是可能的,因为写入按照相同的顺序应用于领导者和追随者,并且每个节点在复制日志中具有一个位置(在本地应用的写入次数)。通过从领导者的当前位置中减去随从者的当前位置,您可以测量复制滞后量。

2
ch7.md
View File

@ -827,7 +827,7 @@ WHERE room_id = 123 AND
与串行执行相比可序列化快照隔离并不局限于单个CPU核的吞吐量FoundationDB将检测到的序列化冲突分布在多台机器上允许扩展到很高的吞吐量。即使数据可能跨多台机器进行分区事务也可以在保证可序列化隔离等级的同时读写多个分区中的数据【54】。
中止率显影响SSI的整体表现。例如长时间读取和写入数据的事务很可能会发生冲突并中止因此SSI要求同时读写的事务尽量短只读长事务可能没问题。对于慢事务SSI可能比两阶段锁定或串行执行更不敏感。
中止率显影响SSI的整体表现。例如长时间读取和写入数据的事务很可能会发生冲突并中止因此SSI要求同时读写的事务尽量短只读长事务可能没问题。对于慢事务SSI可能比两阶段锁定或串行执行更不敏感。

2
ch8.md
View File

@ -641,7 +641,7 @@ while(true){
在本章中,我们讨论了分布式系统中可能发生的各种问题,包括:
* 当您尝试通过网络发送数据包时,数据包可能会丢失或任意延迟。同样,答复可能会丢失或延迟,所以如果你没有得到答复,你不知道消息是否通过。
* 节点的时钟可能会与其他节点显不同步尽管您尽最大努力设置NTP它可能会突然跳转或跳回依靠它是很危险的因为您很可能没有好的测量你的时钟的错误间隔。
* 节点的时钟可能会与其他节点显不同步尽管您尽最大努力设置NTP它可能会突然跳转或跳回依靠它是很危险的因为您很可能没有好的测量你的时钟的错误间隔。
* 一个进程可能会在其执行的任何时候暂停一段相当长的时间(可能是因为世界上的垃圾收集器),被其他节点宣告死亡,然后再次复活,却没有意识到它被暂停了。
这类**部分失效**可能发生的事实是分布式系统的决定性特征。每当软件试图做任何涉及其他节点的事情时,偶尔就有可能会失败,或者随机变慢,或者根本没有响应(最终超时)。在分布式系统中,我们试图在软件中建立**部分失效**的容错机制,这样整个系统即使在某些组成部分被破坏的情况下,也可以继续运行。