mirror of
https://github.com/Vonng/ddia.git
synced 2025-01-05 15:30:06 +08:00
unify the translation of cluster
This commit is contained in:
parent
aa339c313d
commit
ed9acfd65b
2
ch4.md
2
ch4.md
@ -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
2
ch5.md
@ -581,7 +581,7 @@
|
||||
|
||||
然而,法定人数(如迄今为止所描述的)并不像它们可能的那样具有容错性。网络中断可以很容易地将客户端从大量的数据库节点上切断。虽然这些节点是活着的,而其他客户端可能能够连接到它们,但是从数据库节点切断的客户端来看,它们也可能已经死亡。在这种情况下,剩余的可用节点可能会少于w或r,因此客户端不再能达到法定人数。
|
||||
|
||||
在一个大型的群集中(节点数量明显多于n个),网络中断期间客户端可能仍能连接到一些数据库节点,但又不足以组成一个特定值的法定人数。在这种情况下,数据库设计人员需要权衡一下:
|
||||
在一个大型的集群中(节点数量明显多于n个),网络中断期间客户端可能仍能连接到一些数据库节点,但又不足以组成一个特定值的法定人数。在这种情况下,数据库设计人员需要权衡一下:
|
||||
|
||||
* 对于所有无法达到w或r节点法定人数的请求,是否返回错误是更好的?
|
||||
* 或者我们是否应该接受写入,然后将它们写入一些可达的节点,但不在这些值通常所存在的n个节点上?
|
||||
|
4
ch6.md
4
ch6.md
@ -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)所示的路由层。 HBase,SolrCloud和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
2
ch8.md
@ -59,7 +59,7 @@
|
||||
|
||||
在本书中,我们将重点放在实现互联网服务的系统上,这些系统通常与超级计算机看起来有很大不同:
|
||||
|
||||
* 许多与互联网有关的应用程序都是**在线(online)**的,因为它们需要能够随时以低延迟服务用户。使服务不可用(例如,停止群集以进行修复)是不可接受的。相比之下,像天气模拟这样的离线(批处理)工作可以停止并重新启动,影响相当小。
|
||||
* 许多与互联网有关的应用程序都是**在线(online)**的,因为它们需要能够随时以低延迟服务用户。使服务不可用(例如,停止集群以进行修复)是不可接受的。相比之下,像天气模拟这样的离线(批处理)工作可以停止并重新启动,影响相当小。
|
||||
|
||||
* 超级计算机通常由专用硬件构建而成,每个节点相当可靠,节点通过共享内存和**远程直接内存访问(RDMA)**进行通信。另一方面,云服务中的节点是由商用机器构建而成的,由于规模经济,可以以较低的成本提供相同的性能,而且具有较高的故障率。
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user