diff --git a/ch10.md b/ch10.md index de0f0dd6980230bb5076f111550029d9d2252f29..411179730a9debd6daaaf2cacda26ada0f6690e3 100644 --- a/ch10.md +++ b/ch10.md @@ -143,7 +143,7 @@ top5.each{|count, url| puts "#{count} #{url}" } # 5 这种方法 —— 自动化，快速原型设计，增量式迭代，对实验友好，将大型项目分解成可管理的块 —— 听起来非常像今天的敏捷开发和DevOps运动。奇怪的是，四十年来变化不大。 -​ `sort`工具是一个很好的例子。可以说它比大多数编程语言标准库中的实现（即使有很大好处，也不会溢出到磁盘或使用多线程）要更好。然而，单独使用`sort` 几乎没什么用。它只能与其他Unix工具（如`uniq`）结合使用。 +​ `sort`工具是一个很好的例子。可以说它比大多数编程语言标准库中的实现（它们不会利用磁盘或使用多线程，即使这样做有很大好处）要更好。然而，单独使用`sort` 几乎没什么用。它只能与其他Unix工具（如`uniq`）结合使用。 ​ 像 `bash`这样的Unix shell可以让我们轻松地将这些小程序组合成令人讶异的强大数据处理任务。尽管这些程序中有很多是由不同人群编写的，但它们可以灵活地结合在一起。 Unix如何实现这种可组合性？ diff --git a/ch11.md b/ch11.md index e73577143edfb1df3abed2765eefc3847a3b68c3..e9752c8b13473db46c55ed499e4dfa33d7bf02c4 100644 --- a/ch11.md +++ b/ch11.md @@ -43,7 +43,7 @@ ​ 在批处理中，文件被写入一次，然后可能被多个作业读取。类似地，在流处理术语中，一个事件由**生产者（producer）**（也称为**发布者（publisher）**或**发送者（sender）**）生成一次，然后可能由多个**消费者（consumer）**（**订阅者（subscribers）**或**接收者（recipients）**）进行处理【3】。在文件系统中，文件名标识一组相关记录；在流媒体系统中，相关的事件通常被聚合为一个**主题（topic）**或**流（stream）**。 -​ 原则上将，文件或数据库就足以连接生产者和消费者：生产者将其生成的每个事件写入数据存储，且每个消费者定期轮询数据存储，检查自上次运行以来新出现的事件。这实际上正是批处理在每天结束时处理当天数据时所做的事情。 +​ 原则上讲，文件或数据库就足以连接生产者和消费者：生产者将其生成的每个事件写入数据存储，且每个消费者定期轮询数据存储，检查自上次运行以来新出现的事件。这实际上正是批处理在每天结束时处理当天数据时所做的事情。 ​ 但当我们想要进行低延迟的连续处理时，如果数据存储不是为这种用途专门设计的，那么轮询开销就会很大。轮询的越频繁，能返回新事件的请求比例就越低，而额外开销也就越高。相比之下，最好能在新事件出现时直接通知消费者。 @@ -117,7 +117,7 @@ **图11-1 （a）负载平衡：在消费者间共享消费主题；（b）扇出：将每条消息传递给多个消费者。** -​ 两种模式可以组合使用：例如，两个独立的消费者组可以每组各订阅一个主题，每一组组都共同收到所有消息，但在每一组内部，每条消息仅由单个节点处理。 +​ 两种模式可以组合使用：例如，两个独立的消费者组可以每组各订阅一个主题，每一组都共同收到所有消息，但在每一组内部，每条消息仅由单个节点处理。 #### 确认与重新交付 diff --git a/ch9.md b/ch9.md index b0a25342a6abccefdbbfd2dfa6435ec0f47276e4..e6bbbe2f7b7fa5d1d46241e49df1886538eafa16 100644 --- a/ch9.md +++ b/ch9.md @@ -831,7 +831,7 @@ #### 共识的局限性 -​ 共识算法对于分布式系统来说是一个巨大的突破：它为其他充满不确定性的系统带来了基础的安全属性（一致同意，完整性和有效性），然而它们还能保持容错（只要多数节点正常工作且可达，就能取得进展）。它们提供了全序广播，因此也可以它们也可以以一种容错的方式实现线性一致的原子操作（参见“[使用全序广播实现线性一致性存储](#使用全序广播实现线性一致性存储)”）。 +​ 共识算法对于分布式系统来说是一个巨大的突破：它为其他充满不确定性的系统带来了基础的安全属性（一致同意，完整性和有效性），然而它们还能保持容错（只要多数节点正常工作且可达，就能取得进展）。它们提供了全序广播，因此它们也可以以一种容错的方式实现线性一致的原子操作（参见“[使用全序广播实现线性一致性存储](#使用全序广播实现线性一致性存储)”）。 ​ 尽管如此，它们并不是在所有地方都用上了，因为好处总是有代价的。 @@ -889,7 +889,7 @@ ​ ZooKeeper，etcd和Consul也经常用于服务发现——也就是找出你需要连接到哪个IP地址才能到达特定的服务。在云数据中心环境中，虚拟机连续来去常见，你通常不会事先知道服务的IP地址。相反，你可以配置你的服务，使其在启动时注册服务注册表中的网络端点，然后可以由其他服务找到它们。 -​ 但是，服务发现是否需要达成共识还不太清楚。 DNS是查找服务名称的IP地址的传统方式，它使用多层缓存来实现良好的性能和可用性。从DNS读取是绝对不线性一致性的，如果DNS查询的结果有点陈旧，通常不会有问题【109】。 DNS对网络中断的可靠性和可靠性更为重要。 +​ 但是，服务发现是否需要达成共识还不太清楚。 DNS是查找服务名称的IP地址的传统方式，它使用多层缓存来实现良好的性能和可用性。从DNS读取是绝对不线性一致性的，如果DNS查询的结果有点陈旧，通常不会有问题【109】。 DNS的可用性和对网络中断的鲁棒性更重要。 ​ 尽管服务发现并不需要共识，但领导者选举却是如此。因此，如果你的共识系统已经知道领导是谁，那么也可以使用这些信息来帮助其他服务发现领导是谁。为此，一些共识系统支持只读缓存副本。这些副本异步接收共识算法所有决策的日志，但不主动参与投票。因此，它们能够提供不需要线性一致性的读取请求。