unify the translation of cluster

This commit is contained in:
Yin Gang 2021-08-19 09:39:26 +08:00
parent aa339c313d
commit ed9acfd65b
4 changed files with 5 additions and 5 deletions

2
ch4.md
View File

@ -496,7 +496,7 @@ Actor模型是单个进程中并发的编程模型。逻辑被封装在actor中
三个流行的分布式actor框架处理消息编码如下
* 默认情况下Akka使用Java的内置序列化不提供前向或后向兼容性。 但是你可以用类似Prototol Buffers的东西替代它从而获得滚动升级的能力【50】。
* Orleans 默认使用不支持滚动升级部署的自定义数据编码格式; 要部署新版本的应用程序,您需要设置一个新的集,将流量从旧集迁移到新集,然后关闭旧集【51,52】。 像Akka一样可以使用自定义序列化插件。
* Orleans 默认使用不支持滚动升级部署的自定义数据编码格式; 要部署新版本的应用程序,您需要设置一个新的集,将流量从旧集迁移到新集,然后关闭旧集【51,52】。 像Akka一样可以使用自定义序列化插件。
* 在Erlang OTP中对记录模式进行更改是非常困难的尽管系统具有许多为高可用性设计的功能。 滚动升级是可能的但需要仔细计划【53】。 一个新的实验性的`maps`数据类型2014年在Erlang R17中引入的类似于JSON的结构可能使得这个数据类型在未来更容易【54】。

2
ch5.md
View File

@ -581,7 +581,7 @@
然而法定人数如迄今为止所描述的并不像它们可能的那样具有容错性。网络中断可以很容易地将客户端从大量的数据库节点上切断。虽然这些节点是活着的而其他客户端可能能够连接到它们但是从数据库节点切断的客户端来看它们也可能已经死亡。在这种情况下剩余的可用节点可能会少于w或r因此客户端不再能达到法定人数。
在一个大型的集中节点数量明显多于n个网络中断期间客户端可能仍能连接到一些数据库节点但又不足以组成一个特定值的法定人数。在这种情况下数据库设计人员需要权衡一下
在一个大型的集节点数量明显多于n个网络中断期间客户端可能仍能连接到一些数据库节点但又不足以组成一个特定值的法定人数。在这种情况下数据库设计人员需要权衡一下
* 对于所有无法达到w或r节点法定人数的请求是否返回错误是更好的
* 或者我们是否应该接受写入然后将它们写入一些可达的节点但不在这些值通常所存在的n个节点上

4
ch6.md
View File

@ -206,7 +206,7 @@
![](img/fig6-6.png)
**图6-6 将新节点添加到每个节点具有多个分区的数据库集。**
**图6-6 将新节点添加到每个节点具有多个分区的数据库集。**
原则上您甚至可以解决集群中的硬件不匹配问题通过为更强大的节点分配更多的分区可以强制这些节点承载更多的负载。在Riak 【15】Elasticsearch 【24】Couchbase 【10】和Voldemort 【25】中使用了这种再平衡的方法。
@ -278,7 +278,7 @@
例如LinkedIn的Espresso使用Helix 【31】进行集群管理依靠ZooKeeper实现了如[图6-8](img/fig6-8.png)所示的路由层。 HBaseSolrCloud和Kafka也使用ZooKeeper来跟踪分区分配。 MongoDB具有类似的体系结构但它依赖于自己的**配置服务器config server** 实现和mongos守护进程作为路由层。
Cassandra和Riak采取不同的方法他们在节点之间使用**流言协议gossip protocol** 来传播集状态的变化。请求可以发送到任意节点,该节点会转发到包含所请求的分区的适当节点([图6-7](img/fig6-7.png)中的方法1。这个模型在数据库节点中增加了更多的复杂性但是避免了对像ZooKeeper这样的外部协调服务的依赖。
Cassandra和Riak采取不同的方法他们在节点之间使用**流言协议gossip protocol** 来传播集状态的变化。请求可以发送到任意节点,该节点会转发到包含所请求的分区的适当节点([图6-7](img/fig6-7.png)中的方法1。这个模型在数据库节点中增加了更多的复杂性但是避免了对像ZooKeeper这样的外部协调服务的依赖。
Couchbase不会自动重新平衡这简化了设计。通常情况下它配置了一个名为moxi的路由层它会从集群节点了解路由变化【32】。

2
ch8.md
View File

@ -59,7 +59,7 @@
在本书中,我们将重点放在实现互联网服务的系统上,这些系统通常与超级计算机看起来有很大不同:
* 许多与互联网有关的应用程序都是**在线online**的,因为它们需要能够随时以低延迟服务用户。使服务不可用(例如,停止集以进行修复)是不可接受的。相比之下,像天气模拟这样的离线(批处理)工作可以停止并重新启动,影响相当小。
* 许多与互联网有关的应用程序都是**在线online**的,因为它们需要能够随时以低延迟服务用户。使服务不可用(例如,停止集以进行修复)是不可接受的。相比之下,像天气模拟这样的离线(批处理)工作可以停止并重新启动,影响相当小。
* 超级计算机通常由专用硬件构建而成,每个节点相当可靠,节点通过共享内存和**远程直接内存访问RDMA**进行通信。另一方面,云服务中的节点是由商用机器构建而成的,由于规模经济,可以以较低的成本提供相同的性能,而且具有较高的故障率。